Jon Gjengset

Glad to hear you found it useful! Hopefully the API and documentation was also understandable?

Looking at that code, I feel like you'd be better off creating a `Receiver` for every watcher, instead of giving them an `Arc` that they then have to lock each...

I think my recommendation would be to have each `Handler` have an `Option` as well as the `Arc`. If their `Option` is `None`, then they get a new one from...

Using `bound == 0` as a synchronizing channel makes a lot of sense, though unfortunately (as I referenced in that issue), making the implementation support this use-case is actually fairly...

I think @habnabit would be a good person to ping here, as they did a bunch of related work over in https://github.com/jonhoo/bus/pull/15, culminating in https://github.com/habnabit/bus/tree/async_bus

Hmm, that's an interesting feature... It'd be pretty tricky to add, because the value may already have gone out to _some_ readers, and others may be accessing it concurrently. I...

Hmm, yeah, I'd worry that this would end up adding significant contention for both reads and writes, which is something the current implementation tries very hard to avoid. It could...

That's not currently possible because the writer needs to know how many readers there are. It _is_ possible to add more readers at runtime using `add_rx` on the `Bus` though!

`Parker` may also be a good thing to use instead of our `thread::Thread`.

I agree. The goal is to switch to adaptive backoff spinning, but I'd prefer to not implement it myself. I'm half-waiting for mvdnes/spin-rs#29 to be fixed, and then simply use...