-
-
Notifications
You must be signed in to change notification settings - Fork 113
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
Use refcounting for results #374
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In particular: - resultsCapTable has been vestigial since we stopped clearing the CapTable on send, and I've been meaning to delete it. Instead, we just use the message's cap table directly, which also simplifies some code. - We no longer need the code that releases Clients from the result's CapTable -- this is done by msg.Reset when we free the message. In principle, this shouldn't have hurt since Client.Release() is idempotent, but the way we were doing it caused the data race in capnproto#352 Instead, we only need to release the additional items in exports if releaseResultCaps = true.
a4c11d8
to
1da3d5d
Compare
There is no functional change here yet; this just factors the recounting we were already doing into a package, and exposes the ability to refcount to other parts of the code. This is a stepping stone towards addressing capnproto#349; the idea is that the method receiver should get a reference to this too to keep it alive for the right amount of time.
lthibault
requested changes
Dec 7, 2022
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.
...even if we don't actually send. We were seeing tests leaking the bootstrap interface when going down the first branch in the select.
Merged #373 back into this. |
These were added after we branched, so they need updating too.
lthibault
approved these changes
Dec 8, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stacked on top of #373.
There is no functional change here yet; this just factors the recounting
we were already doing into a package, and exposes the ability to
refcount to other parts of the code.
This is a stepping stone towards addressing #349; the idea is that the
method receiver should get a reference to this too to keep it alive for
the right amount of time.