Skip to content

Clarify comments#308

Merged
zenhack merged 2 commits into
capnproto:mainfrom
zenhack:clarify-comments
Sep 30, 2022
Merged

Clarify comments#308
zenhack merged 2 commits into
capnproto:mainfrom
zenhack:clarify-comments

Conversation

@zenhack

@zenhack zenhack commented Sep 26, 2022

Copy link
Copy Markdown
Contributor

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