Add a @pub kwarg to allow specifying a "startup response message"#258
Closed
Add a @pub kwarg to allow specifying a "startup response message"#258
Conversation
Owner
Author
|
I'm thinking we should do a rewrite of this using the new bi-dir streaming + |
Owner
Author
|
Heh, yeah this is totally obsolete and if anything similar were to be patched, it'd be based on the new Closing. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a fix for an (old and) undocumented feature that enabled async generator based "pub-sub" streaming such that during stream connection startup an initial "message" is sent to each new subscriber much like how the new
tractor.Context.started()works for bidirectional streaming setup.This patch in particular was pulled out of historical work on the
infect_asynciobranch.I'm not even sure this undocumented internal "pub sub" api should even be kept since it is basically just a multiplexed (read non-task oriented) version of what you can already do easily with our task-broadcast receiver apis and a single producer actor.
It's probably worth making a so called dynamic pub-sub example using the newer APIs for comparision, maybe do some brief perf benchmarks and then decide if we should just drop this interface?