postage-rs VS pollster

Here are a few things that I learned from writing postage that might be helpful: - Poll::Pending can cause subtle deadlock bugs. If a channel endpoint is going to return Poll::Pending, it needs to check conditions, register for notification, and then re-check those conditions before returning Pending. Otherwise, the endpoints could deadlock due to concurrent interactions between the channel state and the notifier. Here's an example fix on an mpsc channel: https://github.com/austinjones/postage-rs/commit/9d2ba3f83dcbbcef83c684462f5efc5b3e7681cc - The single-threaded cases around sender/receiver polls can be covered in unit tests. Tests can verify the poll result, as well as waker interactions. Here's an example: https://github.com/austinjones/postage-rs/blob/main/src/channels/mpsc.rs#L242

I ran into the same thing with Stream - had tons of code that merged/mapped/filtered channel receivers. I ended up deciding to write an async channel library called postage to replace that functionality.

In case anyone is late to the party, I published v0.4.0 with: - a dispatch channel (mpmc queue) - borrow_mut for the watch sender (so you can mutate the value stored in the channel) - .blocking_send() and .blocking_recv() - And a CI matrix, removing the 'beta' tag.

I'm working on postage, an async channel library. Postage provides mpsc/broadcast/watch/oneshot channels, as well as Sink and Stream combinators.

Other than that, I'm using async mostly not in a web-based environment, unlike your assumption that the "so-called web-devs" only want to use it. It's also quite flexible, you want it blocking? Start a blocking executor. You don't want tokio for that? Use a minimal executor like https://github.com/zesterer/pollster for that...

Check out https://github.com/zesterer/pollster. This can be the solution to the async problem you described

Pollster: https://github.com/zesterer/pollster