Repository navigation
Lazy broadcast channel #373
Description
What's needed
Still need to come up with a new name for this broadcast channel configuration, but I think it would be nice to get broadcast channels that pause on overflowing receivers. (without blocking sender.send)
Receiver behaviour
When a receiver is not being consumed from for a certain duration, the channel stops sending to it. If the receiver is awaited again, it gets treated like a new receiver, starting with an empty buffer, and respecting resend_latest.
Sender behaviour
The send methods don't block, so it is the same behaviour as now, but the sender has a property and an async method which can be used to prevent wasteful work, like this:
if not sender.has_active_receivers:
await sender.wait_for_receivers()This would prevent the sending side from doing active work, and possibly stop receiving from its upstream and stop work on that level as well.
So channels would finally transmit information about receivers to the sending side, if they are interested.
Activity
[-]What's needed[/-][+]Lazy broadcast channel[/+]llucax commentedon Feb 27, 2025
So, would this be a complement for #20?
BTW, I don't think this needs to be assigned to v2, as it can be implemented as a new feature (in v2 we could change defaults, like making this mode of working the default).
shsms commentedon Feb 27, 2025
Wow, I had completely forgotten that was there. Anyway, I think this current proposal offers more flexibility, considering that we haven't had a use case in the past few years where we can't discard some values. Unless we have use cases like writing to disk or reporting to external parties, where it is absolutely critical that we don't drop messages. So maybe we should keep that issue open but separate.
I agree; I put it under 2.0 only to signify that this is not super urgent. I've called it untriaged instead.
llucax commentedon Feb 27, 2025
Yeah, we also have priority tags, but if there is no plan of when to implement it yet, I think Untriaged is the right milestone (not sure if that word is correct, though, maybe the milestone should be called more like Undecided or something like that).
llucax commentedon Feb 27, 2025
Maybe it makes sense to unify them? I guess the problem we are trying to solve is having some sort of synchronization between senders and receivers (so senders can know if there are receivers, and wait for them if they are choking), and we have a couple of possible implementation ideas for that, right?
shsms commentedon Feb 27, 2025
Yes, broadcasts with ack are so tough. I guess the two options are:
My first thought is to extend the above design by adding a
sender.has_inactive_receiversproperty to support the second case.shsms commentedon Feb 27, 2025
Then the receivers can be configured to become inactive either after an interval, or as soon as they become full. And the sender features and receiver features would provide a lot of possibilities.
llucax commentedon Feb 27, 2025
Because it seems it is still unclear how we want to solve this, I'm inclined to convert this issue into a discussion and repurpose #20 as an issue only presenting the requirements, and linking to the discussion, until we have a concrete (actionable) implementation plan.