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

Fix #420 #424

Merged
merged 5 commits into from
Jan 13, 2023
Merged

Fix #420 #424

merged 5 commits into from
Jan 13, 2023

Conversation

zenhack
Copy link
Contributor

@zenhack zenhack commented Jan 13, 2023

This fixes #420 (without re-introducing #394, or #349). Per the last commit:

420 was a regression introduced by our fix for 394; if we Return()
before we fulfill(), this can result in out of order message delivery,
since incoming calls can be made directly on clients in the result
before all queued calls are drained.

Previously, if we fulfilled() before Return(), we would get a data race
as fillPayloadCapTable modified the message while pipelined calls read
it. Having split Return(error) into PrepareReturn(error) and Return(),
it is now safe to move just the latter after the call to fulfill().

I am now unable to reproduce any of the referenced issues.

No functional change, but this is in preparation to address capnproto#420; we
will have to separate these across two separate calls in Returner.
See the comments. No functional change yet, since all call sites
currently call PrepareReturn and Return in immediate succession, but
presently this separation will be used to fix a race condition.
(without re-introducing capnproto#394)

420 was a regression introduced by our fix for 394; if we Return()
before we fulfill(), this can result in out of order message delivery,
since incoming calls can be made directly on clients in the result
before all queued calls are drained.

Previously, if we fulfilled() before Return(), we would get a data race
as fillPayloadCapTable modified the message while pipelined calls read
it. Having split Return(error) into PrepareReturn(error) and Return(),
it is now safe to move just the latter after the call to fulfill().
lthibault
lthibault previously approved these changes Jan 13, 2023
capability.go Outdated Show resolved Hide resolved
...based on Louis's feedback.
@lthibault
Copy link
Collaborator

--- FAIL: TestSendDisembargo (0.01s)
    --- FAIL: TestSendDisembargo/SendQueuedResultToCaller (0.01s)
Error:         level1_test.go:285: Received finish message; want disembargo
Error:         level0_test.go:2126: conn error: rpc: send release: send message: context canceled

@zenhack
Copy link
Contributor Author

zenhack commented Jan 13, 2023

...that's one of the existing ones.

@lthibault
Copy link
Collaborator

Yeah, I thought so, but couldn't find an issue for it. The error in #377 is a different one.

Should I open an issue for this? (Re-running CI in the meantime.)

@zenhack
Copy link
Contributor Author

zenhack commented Jan 13, 2023

Yeah, why don't you open a separate one; I think this one's been around a while but I keep binning it with #377

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.

TestPipelineCall fails
2 participants