Skip to content
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

handleCall: cleanups & locking simplifications #403

Merged
merged 5 commits into from
Dec 28, 2022

Conversation

zenhack
Copy link
Contributor

@zenhack zenhack commented Dec 27, 2022

This gets us to a place where locking in handleCall is strictly hierarchical; there is one call to syncutil.With and then later a lock(); defer unlock().

I don't love the way we're using releaseList to do the actual Recv calls, but factoring those out into one codepath turned out to be really thorny. This is at least cleaner than what we had before, and gets this into a shape where it can be easily adapted to the withLocked() design we'd discussed.

I'm also not a fan of how many codepaths have to call releaseCall, but cleaning up resource reclamation is another broader topic on my list...

This also includes a couple minor cleanups in 5617569 and 28f46de

Giving this a name makes it easier to follow what's going on here.
I don't love this, but at least it gets us to a place where the locking
is reasonably simple.
lthibault
lthibault previously approved these changes Dec 28, 2022
rpc/rpc.go Outdated Show resolved Hide resolved
Per Louis's suggestion
@lthibault lthibault merged commit 6d8c1b2 into capnproto:main Dec 28, 2022
@zenhack zenhack deleted the handleCall-locking branch December 28, 2022 20:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants