"No, its fine! I want to consider..." <- To share my (limited) experience (not sure that would help or bring more confusion, but oh well): - I've found the notion of a central "Broadcasting" message bus very appealing too so what you are asking for is close to my heart. :) For example, [here](https://github.com/ivmarkov/fiat-a2dp/blob/master/src/bus.rs). - To avoid the dangers of SPMC "broadcast" channels (one lagging receiver stucks the whole channel for all others OR the broadcast queue starts dropping the oldest messages) I just use what you and James Munns suggest - a "watch" of sorts _that only reports the last value_. - Since such a type is not available out of the box in embassy (contrary to what James said, a broadcast channel does exist in `embassy-sync` - the [embassy MPMC channel](https://github.com/embassy-rs/embassy/blob/1cf778904d597a5bc01a4b7862f965681636faf1/embassy-sync/src/pubsub/mod.rs#L30 but it is a typical broadcast queue with the above broadcasting pitfalls so I avoid that), I just use regular - multiple instances of - `embassy_sync::signal::Signal`s - Where the value of the signal (`T`) is too big so moving it might incur non-trivial memory usage, I [also use a `StatefulSignal`](https://github.com/ivmarkov/fiat-a2dp/blob/355d19936ec73d7ccc9a0c91b995006bccaf1215/src/signal.rs#L67) of sorts, which is nothing else, but the suggestion of James - a Mutex plus a waiter registration - To turn the SPSC `Signal` into SPMC (a tokio "watch" of sorts), I simply [use an array of `Signal`s or `StatefulSignal`s](https://github.com/ivmarkov/fiat-a2dp/blob/355d19936ec73d7ccc9a0c91b995006bccaf1215/src/signal.rs#L12) which is as big as _all the subscribers_ that that would ever be interested in the signal value. As for routing - I just solved it in the most brute force way possible - no routing. :D [Every task get a subscription to **every** SPMC signal](https://github.com/ivmarkov/fiat-a2dp/blob/355d19936ec73d7ccc9a0c91b995006bccaf1215/src/audio.rs#L147), even if the concrete task might not be interested in the value of a particular signal (this solution has memory size consequences of course). Since the bus only uses "last value", the fact that a task might never consume a signal it is "subscribed" to, is not a problem at all. If I can summarize, for me - if you could organize all your logic around "last value" only - signals (as opposed to M/SPMC broadcast queues) are a god-send! Not only because of the complete absence of the "lagging subscriber" issue, but also because publishing to signals is both non-blocking and not-async, so there is just no way to cause channel overflow and deadlocks. Also, since the BT stack of my concrete example is callback-based rather than async, using signals [is a very simple way to plug a callback solution into the whole async circus](https://github.com/ivmarkov/fiat-a2dp/blob/355d19936ec73d7ccc9a0c91b995006bccaf1215/src/bt.rs#L205) and make the callback code behaving.