bus
bus copied to clipboard
jonhoo
[WIP] Add back the async bus
Wow this is incomplete! The tests don't pass per se, but that's on purpose. It does demonstrate the concept and that it can be implemented easily enough. There's even a little code deduplication.
well, i'm partway through this and finding some deadlocks in the async code. would hopping back on irc be an option for debugging this? if not, i can post what i have and explain what i'm seeing.
I'm unfortunately busy today (about to do a Rust live-coding session :D), but could try to get on IRC some time tomorrow. What's your timezone?
Is there still interest in merging this or something like it? It would be useful for a project I'm working on. If the original author doesn't want to work on it, I'd be willing to take a stab at finishing this up and later porting it to std::futures.
btw, I did make a completely separate reimplementation of this wherein I solved the issues I was running into at the expense of making it not generic to sync/async anymore: https://github.com/habnabit/bus/tree/async_bus
there was another comment I made about the overall structure of async_bus and the lessons I learned but I can't find it at the moment.
ah, found it: https://github.com/crossbeam-rs/crossbeam-channel/pull/38#issuecomment-410117965
I'm taking a stab at writing a Futures 0.3+ version of this.
It seems to me that this would alter the architecture even more than @habnabit's async_bus rewrite. The biggest change would be to leverage AtomicWaker, remove the background waker thread/channels, and eliminate (or move, really) thread parking altogether. This would make the API async-first, then the non-blocking calls would be implemented in terms of poll*, and blocking calls would be implemented in futures::block_on or similar.
@jonhoo - Is this a direction you'd want the implementation to go? If not, I guess it'd have to be a forever-fork, which doesn't sound pleasant.
I'm very wary of implementing the sync version of this using something like futures::block_on, as it tends to have really weird performance properties and not compose well. I think in practice it's actually probably better to have the async implementation be entirely separate rather than trying to share the impl across sync and async.
Hey, any news regarding this? I guess its stalled, any plans on a rewrite or some future plans regarding async?
Hey, any news regarding this? I guess its stalled, any plans on a rewrite or some future plans regarding async?
I ended up implementing the async rewrite, but it did end up basically as a rewrite. After implementing it, I think I agree with @jonhoo. It'd be hard to reconcile these as different flavors of the same implementation. It should just be a separate impl.
Some MPMC schemes like Flume have managed to be both Sync and Async, but they're not broadcast. I vaguely recall that broadcast did invoke some additional complications for the sync+async APIs, but the details escape me at the moment.
After I implemented it, we shifted the architecture of our system and my async version is no longer in use.