New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow apps using the bridge to respond to powerbox requests & offers #3222
Conversation
Ok, I think the documentation part of this is ready-ish. I'm sure there are improvements to be made, but I think the proposed interface is at least described now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My value in reviewing Powerbox API code is... limited... but I can definitely review docs for readability. ;)
OK! the version of the code here is "done;" I'd like to add a couple automated tests, but those will probably cause some annoying conflicts with #3221, whereas the rest of these two prs merges cleanly. I've got the filesystem demo working with this well enough to have some confidence though (there are a few bugs in the demo that are clearly not related to the bridge). I consider this ready for review. |
The next few commits will flesh out relevant documentation to mention the header described in the comments, and describe how to use these methods. All this will serve as a more precise spec for what to implement.
Still need to talk about offer sessions.
Not tested (though it doesn't break the existing tests).
Thanks to @ocdtrekkie for spotting these.
We're going to start tweaking this to support offer & request sessions, so now is a good time to do this cleanup.
This needs further testing, but is now feature complete wrt. sandstorm-io#3197
It now doesn't crash until those methods are called, rather than on creation. I'm going to put this down for a bit and come back when I have the mental energy to sit down and understand what's going on.
Apparently I messed this up when factoring out the logic.
...mostly in place of kj::mv. At least one of these was responsible for some memory corruption I was seeing. Some of the copies this introduces *may* be unnecessary, but it's probably better to have the copy in there than the unsafe cast, until it is demonstrably a problem.
See the comments for the current state of affairs. The code I'd written previously didn't have any coherent story here, and was *sometimes* working I think just because of luck wrt. what memory gets re-used by the allocator or doesn't. This needs more testing, but experimenting with my filesystem demo, grains, it gets further than anything before it.
Merged "cleanly", but there are some build errors now. Investigating. |
...instead of three, per @kentonv's suggestion.
Readers are already reference types, so let's just store that directly.
Starting with just spec'ing out the solution I described in #3197 precisely; I've done the capnproto parts of this, and will push subsequent commits that update other relevant parts of the docs. Once that's in place and folks are happy with the API, I'll start implementing. I'll probably wait until #3221 is merged and rebase on top of that to avoid potential conflicts.