Tokio:mpsc vs futures:mpsc

Is there any difference between the two implementations ? In my project i am using both Hyper and Tokio crates and I have dependency on both channels.

I don't know about Tokio, but the stdlib mpsc channels are quite slow. Instead of using that, have a look at crossbeam's MPMC channels, which are faster than the stdlib mpsc. Crossbeam's channels also support multiple consumers, to boot.

true, you have just added two more ways for implementing channels.
here i am not talking about stdlib:mpsc but about mpsc implementation provided by tokio and futures crates.
originally I used crossbeam but run into some problems with async/.await. so switched to futures::channel.
I do like the idea of having multiple senders though.

The Tokio channels support async await and you can use await to wait for an item instead of blocking the thread like both std and crossbeam would do.

hey @alice
futures::channel also support async/.await

The buffer size of a futures bounded mpsc can be zero, but a tokio mpsc will panic if you do that. In this regard, the futures mpsc's behavior is closer to Go.

Separately, async-std's channel has a simpler API, but that choice generated a lot of discussions.

1 Like

That 0 buffer size gives a wrong impression. The futures channel is always buffered. It will have the configured buffer size (0) plus one buffer per Sender.

Therefore it won’t behave different than the tokio channel with a capacity of 1.

The only unbuffered async channel implementation so far is in futures-intrusive. It supports direct handoff between producer and consumer.


Adding a note for future readers, the behavior between futures mpsc and tokio mpsc with a bound of 1 is not equivalent because with Tokio all producers will block until their message can be sent (except the first), whereas in futures mpsc the send can complete immediately.

To emulate futures' with tokio's you'd have to spawn a task on the send so that you don't block locally or you have to move your await point (depending on if there's a logical place for that, which there may not be).