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

Ctx result consumption #319

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from
Draft

Ctx result consumption #319

wants to merge 6 commits into from

Conversation

goodboy
Copy link
Owner

@goodboy goodboy commented Jul 27, 2022

Better handling of contex teardowns where IPC msgs might still be in transit that need to be discarded as well a more explicit tolerance for IPC transport failures when determining whether to send cancel request messages.

@goodboy goodboy force-pushed the signint_saviour branch 4 times, most recently from d1ddfa4 to 2d387f2 Compare August 2, 2022 16:18
Base automatically changed from signint_saviour to master August 3, 2022 13:26
@goodboy
Copy link
Owner Author

goodboy commented Oct 6, 2022

well this needs a rebase 😂

@goodboy goodboy changed the base branch from master to harden_cluster_tests December 12, 2022 15:17
@goodboy
Copy link
Owner Author

goodboy commented Dec 12, 2022

This is oddly causing a clustering test hang, seemingly todo with gather_contexts() usage?

Base automatically changed from harden_cluster_tests to master December 12, 2022 20:02
@goodboy goodboy force-pushed the ctx_result_consumption branch 2 times, most recently from 8b93a1b to 2fe9a1a Compare December 12, 2022 20:26
@goodboy
Copy link
Owner Author

goodboy commented Jan 28, 2023

This is oddly causing a clustering test hang, seemingly todo with gather_contexts() usage?

Ahh i wonder if this was solved by #346 (comment)?

Not even sure if this patchset ends up being necessary given all the work in #346, probably worth a test tho.

The case exists where there is multiple tasks consuming from an open
2-way stream created via `Context.open_stream()` where a sibling task is
pulling from the stream while some other task also calls `.result()`.
Previously the `.result()` call would consume (drain) stream messages
directly from the underlying mem chan which would mean any sibling task
would not receive those same messages. Instead, make `.result()` check
if a stream is open and instead consume (and discard) stream msgs using
a `BroadcastReceiver` (via `MsgStream.subscribe()`) such that all
interested tasks get copies of the same packets.
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.

None yet

1 participant