Tokio::sync:mpsc vs futures::channel::mpsc


tokio has it's own implementation of mpsc queue, which differs from implementation in futures. Main difference for me now is that tokio's Sender does not implement Sink trait, which is something I miss.

So questions - why two different implementations? Is anything wrong with futures' mpsc implementation?

Why tokio's Sender does not implement Sink?

Most of this question is answered here. As for the Sink trait, that's because Tokio does not depend on the crate that defines the Sink trait, and doing so would prevent Tokio from reaching v1.0 as having dependencies on pre-1.0 crates in the public API is considered a bad idea in v1.0 crates as it makes updating the dependency a breaking change.

The Stream trait is different because it will be added to the standard library soon, whereas there are no such plans for Sink in the near future.

@alice Thanks, that makes sense, although for me as "regular" user of libraries is probably too subtle. It's rather new to me that Sink is considered not stable enough to be supported in tokio. I'd like to have some common interfaces/trait on which I can rely and Stream - Sink pair seems naturaly to coexist together.

To be fair, the standard library does not have a Sink analogy for the Iterator trait.

@Alice very true. But mostly I think about Streams as kind of pipes, rather then Iterators - probably much influenced by most common use case - the communication - then the other side of pipe - Sink is obvious.

Generally in my experience it is relatively to write code such that Sink is not necessary.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.