Implement a lagging broadcast channel

[austinjones]

I'd like to support the lagging broadcast channel that tokio provides, so postage can be fully compatible with existing tokio code.

I think the current channel is useful, but it needs a new name.

[zeenix]

I'd like to support the lagging broadcast channel that tokio provides, so postage can be fully compatible with existing tokio code.

Tokio's behaviour to me (and some other Rust devs I've talked to) seems a bit wrong, to just drop a message if a receiver is lagging. However, if it's an optional feature, people can just choose the behavior they expect.

[austinjones]

Yeah, I think the tokio behavior is there because writing a broadcast channel with back-pressure is difficult.

The only contetxt that dropping might make sense is in audio/video processing apps (for frames or samples). But in general apps it can cause some wild bugs that are really hard to reproduce.

[zeenix]

The only contetxt that dropping might make sense is in audio/video processing apps (for frames or samples).

@austinjones Just FYI, we realized the need for this "overflow" feature in async-broadcast too after trying to use it in zbus. The issue is that in zbus, we've a thread that reads incoming messages from a socket and sends it across to all the streams (as in futures::stream::Stream) and there is no easy way to ensure all of those streams are always getting pulled. Since we don't need all the messages (if a stream wants all messages, it should just ensure that it keeps pulling), the solution would be to allow overflow.