Add a mpmc channel

[steveklabnik]

Issue by mahkoh
Friday Dec 12, 2014 at 20:26 GMT

For earlier discussion, see rust-lang/rust#19783

This issue was labelled with: A-libs, A-threads in the Rust repository

---

[steveklabnik]

/cc https://github.com/mahkoh/comm

[jonhoo]

FWIW, a spmc channel would also be incredibly useful, and could probably be optimized in ways a mpmc can not.

[viperscape]

@jonhoo I started bulding a spmc lib for rust, though it needs optimizations, and I should probably dump the linked list idea.. oyashio/spmc lib

[19h]

Any updates on this? :-)

[jonhoo]

https://github.com/jonhoo/bus could probably be adapted pretty easily to be spmc instead of sp-broadcast. Will probably simplify the code a fair amount in fact.

[eddyb]

I believe crossbeam's SegQueue is a MPMC channel.
EDIT: SegQueue is non-blocking, but MsQueue looks more like a channel.

[jadbox]

Any update on getting this into Rust core?

[aperrot42]

Would definitely be a useful feature. Is it to be integrated to rust 's sync library ?

[WiSaGaN]

I believe crossbeam-channel has become the community preferred MPMC channel this year.

[Centril]

@WiSaGaN thanks for the update. Closing this therefore.

[let4be]

What about crossbeam-channel and tokio? Does it work with it or does it work with std threads only?...

[Kixiron]

That's a question for crossbeam, not really a rust rfc

[aWeinzierl]

@Centril I don't quite understand? How does this solve this issue? 🤔

[RustyYato]

Use crossbeam, using dependencies in Rust is easy and painless. So if something can be a dep instead of in std, putting it in a dep is preferred.

[Sebi2020]

Mh, should definitly work without dependencies...

[LunarLambda]

Hello from 2024. Since std's mpsc channels are nowadays based on a mpmc channel (whose implementation is in turn based on crossbeam), is there any possibility of reviving this idea? Apologies for replying to a years old closed issue but this is the only/most recent mention of this topic. The impl !Sync for Receiver<T> (https://doc.rust-lang.org/stable/src/std/sync/mpsc/mod.rs.html#194) does not specify a reason so I assume there's nothing technical stopping this.

I assume this is mainly a naming churn problem, since we can't rename the mpsc module to mpmc, and it would be weird to expose the exact same types through a second module based on a 'semantic' change.

Ultimately I'd love to have this in standard Rust, since it already exists in std anyway, but I'm curious to know what would need to be done to make this happen (besides the obvious 'make an RFC'), what kind of approach would be deemed possible and preferred by the libs team.

[rmnilin]

@Centril @eddyb @jonhoo @Kixiron @WiSaGaN, apologies for the ping, but could we please consider reopening this issue?

I believe that LunarLambda has made excellent points that warrant further comments at least.

The closure of this RFC based on the existence of third-party libraries overlooks the benefits of having this capability integrated into the standard library, especially accessibility, consistent maintenance, and reduced dependency overhead.

Given these points, I believe there is a strong case for revisiting this RFC. Having MPMC channels in the standard library would greatly enhance Rust's concurrency primitives and provide a more robust solution for concurrent programming.

Thank you in advance for considering this request.

[steveklabnik]

@rmnilin issues in the RFC repo are mostly just a place for folks interested in an idea to talk about it. It being open or closed says nothing about the actual state of this. they're not used in any decision making process by the teams.

pull requests are "actual" RFCs that are being actively developed. anyone interested in moving a proposal forward would write an RFC and open a pull request with the RFC itself.

[shepmaster]

Note that the libs team is generally positive to adding this. Someone needs to do the work, however.