-
Notifications
You must be signed in to change notification settings - Fork 9
Open
Labels
part:coreAffects the core types (`Sender`, `Receiver`, exceptions, etc.)Affects the core types (`Sender`, `Receiver`, exceptions, etc.)priority:highAddress this as soon as possibleAddress this as soon as possibletype:enhancementNew feature or enhancement visitble to usersNew feature or enhancement visitble to users
Milestone
Description
What's needed?
It would be nice for select() to be more flexible (add and remove receivers, have optional receivers) without losing its static-ness.
Proposed solution
Improve the composability of existing receivers and create a new one:
- Add a channel or receiver that merges messages from multiple receivers (or recycle
Mergerto do that) and can dynamically add and remove receivers, and just waits forever (it's never ready) when there are no receivers - Maybe add a wrapper on the above that only accepts 0 or 1 receivers, to implement an optional receiver (Add OptionalReceiver for handling unset receivers #409)
- Maybe add a
NopReceiverthat does the same asOptionalReceiver(None)
Use cases
I think many cases where users need to handle lots of tasks manually to cope with more dynamic situations, like the resampler, could be greatly simplified if they could be handled automatically by using a more flexible select.
Alternatives and workarounds
Break the select loop, use tasks manually.
Additional context
This would fix a few open issues / discussions:
Metadata
Metadata
Assignees
Labels
part:coreAffects the core types (`Sender`, `Receiver`, exceptions, etc.)Affects the core types (`Sender`, `Receiver`, exceptions, etc.)priority:highAddress this as soon as possibleAddress this as soon as possibletype:enhancementNew feature or enhancement visitble to usersNew feature or enhancement visitble to users
Type
Projects
Status
To do