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

Clarify comments #308

Merged
merged 2 commits into from
Sep 30, 2022
Merged

Clarify comments #308

merged 2 commits into from
Sep 30, 2022

Conversation

zenhack
Copy link
Contributor

@zenhack zenhack commented Sep 26, 2022

While picking through the code trying to solve #306, I discovered a few bits of the API that were not adequately documented, so I fixed the docs. See individual commits.

This is depended upon in a few places, and from what I can tell is in
fact satisfied by all implementations. But it wasn't documented.
zenhack added a commit to zenhack/go-capnp that referenced this pull request Sep 26, 2022
Documentation added in capnproto#308 makes this redundant; the ReleaseFuncs
returned by the transport already releases any caps in the message,
and in all cases this was called immediately before releasing the
message as a whole. Not doing this at every call site will make things
less brittle.

Note that there is no functional change here, in particular this is not
fixing a double free bug: since clearCapTable sets CapTable to nil, it
doesn't clash with the call to msg.Reset in the ReleaseFunc.
@zenhack zenhack mentioned this pull request Sep 26, 2022
zenhack added a commit to zenhack/go-capnp that referenced this pull request Sep 30, 2022
For two reasons:

1. As clarified in capnproto#308, the transport will release these when the
   message is freed, so we don't need to do this here to avoid a leak,
   and letting the transport deal with it is simpler.
2. I smell a race condition: this releases the clients before the
   message is actually on the wire. I *think* it is actually fine,
   because I think by this time the message is already in the queue and
   so is morally on the wire, but it's a bit harder to reason about,
   and makes me nervous.

I *believe* there is no functional change here.
zenhack added a commit to zenhack/go-capnp that referenced this pull request Sep 30, 2022
For two reasons:

1. As clarified in capnproto#308, the transport will release these when the
   message is freed, so we don't need to do this here to avoid a leak,
   and letting the transport deal with it is simpler.
2. I smell a race condition: this releases the clients before the
   message is actually on the wire. I *think* it is actually fine,
   because I think by this time the message is already in the queue and
   so is morally on the wire, but it's a bit harder to reason about,
   and makes me nervous.

I *believe* there is no functional change here.
@zenhack zenhack merged commit 6ab2f9d into capnproto:main Sep 30, 2022
@zenhack zenhack deleted the clarify-comments branch September 30, 2022 19:01
zenhack added a commit to zenhack/go-capnp that referenced this pull request Sep 30, 2022
For two reasons:

1. As clarified in capnproto#308, the transport will release these when the
   message is freed, so we don't need to do this here to avoid a leak,
   and letting the transport deal with it is simpler.
2. I smell a race condition: this releases the clients before the
   message is actually on the wire. I *think* it is actually fine,
   because I think by this time the message is already in the queue and
   so is morally on the wire, but it's a bit harder to reason about,
   and makes me nervous.

I *believe* there is no functional change here.
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