postage-rs VS concurrent-queue

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.

Hmm, actually I’m not sure. It depends on the implementation of concurrent-queue, since it is built on top of it.

Also adding tail_mut() and head_mut methods to the Concurrent-Queue crate!