Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for mpmc #126840

Open
2 of 4 tasks
obeis opened this issue Jun 22, 2024 · 2 comments
Open
2 of 4 tasks

Tracking Issue for mpmc #126840

obeis opened this issue Jun 22, 2024 · 2 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@obeis
Copy link
Contributor

obeis commented Jun 22, 2024

Feature gate: #![feature(mpmc_channel)]

This is a tracking issue for mpmc_channel as described in ACP.

History

@obeis obeis added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Jun 22, 2024
@jieyouxu jieyouxu added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jun 24, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 1, 2024
Add multi-producer, multi-consumer channel (mpmc)

Closes rust-lang#125712

Tracking issue: rust-lang#126840

r? m-ou-se
@ora-0
Copy link

ora-0 commented Jan 13, 2025

The sync::mpsc module's sync_channel function returned a SyncSender and SyncReceiver type, but the new mpmc module's sync_channel returns just a normal Sender and Receiver type. Is this symmetry something we want to preserve?

This shouldn't affect any usage of them, except for the slightly different documentation provided.

@ibraheemdev
Copy link
Member

ibraheemdev commented Jan 24, 2025

I wonder if there's a downside to SyncSender and Sender being separate types, and you would ever need to create an enum (which is unnecessary because they are internally enum) to switch between them dynamically. This seems unlikely as they have different semantics, but theoretically if you are only using try_send you may want to. I think this is less of a concern than keeping the modules consistent, but the SyncSender naming is itself confusing, so I'm not sure.

Zalathar added a commit to Zalathar/rust that referenced this issue Jan 27, 2025
fix doc for std::sync::mpmc

fix document of `std::sync::mpmc` (tracked in rust-lang#126840)
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jan 27, 2025
fix doc for std::sync::mpmc

fix document of `std::sync::mpmc` (tracked in rust-lang#126840)
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 27, 2025
Rollup merge of rust-lang#135876 - usamoi:mpmc-doc, r=tgross35

fix doc for std::sync::mpmc

fix document of `std::sync::mpmc` (tracked in rust-lang#126840)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants