Add Receiver::new_sender
to channels
#750
Open
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 change gives some
channel::Receiver
s the ability to spawn new senders at will.Currently, Receivers are disconnected as soon as the Sender count reaches zero, as new Senders can only be created by cloning an existing one. Disconnected receivers do not block on
recv
and such, instead they just fail immediately.This didn't quite fit my use case, where I need to have the ability to create new Senders when I want to, and also get the non-blocking behavior if there is no Sender alive. With the current API, I have to keep a prototype Sender which is always alive and which I can clone whenever I want. The problem is that since the prototype is always alive, the channel never gets disconnected. That means calls to
recv
stay blocking, even when we know that no message will ever be sent through the Sender prototype, because its only purpose is to produce new Senders.This change creates a new Receiver type that supports creating new Sender instances. That means, I don't need to keep a Sender prototype anymore, so my Receiver is non-blocking when I know there is no real Sender alive. But even after the channel was disconnected, you can "reconnect" it by spawning new senders.
Obviously this method cannot appear in the API of channel flavours like
tick
ornever
, since the point of those is to expose only a receiver. This means, we need two different types forReceiver
. I put that new API in a separate submodule so that it's easy to import and document. That submodule only supports creating unbounded channels for now, as that was my use case. If you're interested we may be able to add support for bounded and zero channels, but there is AFAIK no risk in keeping an incomplete API here.Please let me know if there is anything you need from me to get this merged faster, be it documentation, tests, etc.
Cheers :)