Lazy broadcast channel

[shsms]

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.

[llucax]

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]

So, would this be a complement for #20?

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.

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).

I agree; I put it under 2.0 only to signify that this is not super urgent. I've called it untriaged instead.

[llucax]

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]

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.

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]

Yes, broadcasts with ack are so tough. I guess the two options are:

• stop sending if none of the receivers are active.
• stop sending if any of the receivers are not active.

My first thought is to extend the above design by adding a sender.has_inactive_receivers property to support the second case.

[shsms]

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]

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.