Avoid object cycle in clientHooks. #509
Merged
Conversation
This file contains hidden or 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
...because fewer special cases are better. This also resolves everything but the documentation for capnproto#423. One of the tests had to be reworked a bit because the exact sequence of messages was a bit different, but still correct.
Per Louis's questions.
This will simplify transitioning to using the rc package for refcounting. Right now there is a bug where one of the tests is failing with an error about multiple shutdowns -- I think this is likely equivalent to capnproto#348 (the done channel is gone), but it seems to be deterministic now.
This Shutdown() is redundant with the one in clientPromise.shutdown(). When capnproto#348 was filed, this was a close() on the done channel instead of a call to ClientHook.Shutdown, but became the latter after merging calls and refs -- done was for the former, Shutdown() for the latter. I'm still not 100% sure why this used to be non-deterministic.
Currently, non-promises are represented by clientHooks whose resolevedHook points back the same clientHook. I want to move these over to the rc package from go-util, but having object cycles like this is going to cause problems. Instead, we just keep track of whether this was a promise in the first place more explicitly: wrap resolvedHook in a Maybe, where absent means this was never a promise. We could use a boolean flag here, but this is more type safe.
lthibault
approved these changes
May 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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 #508, just the last commit is relevant.
Currently, non-promises are represented by clientHooks whose resolevedHook points back the same clientHook.
I want to move these over to the rc package from go-util, but having object cycles like this is going to cause problems. Instead, we just keep track of whether this was a promise in the first place more explicitly: wrap resolvedHook in a Maybe, where absent means this was
never a promise.
We could use a boolean flag here, but this is more type safe.