Skip to content

Document blocking guarantees for std::sync#158679

Open
cyexclam wants to merge 1 commit into
rust-lang:mainfrom
cyexclam:sync-document-blocking-guarantees
Open

Document blocking guarantees for std::sync#158679
cyexclam wants to merge 1 commit into
rust-lang:mainfrom
cyexclam:sync-document-blocking-guarantees

Conversation

@cyexclam

@cyexclam cyexclam commented Jul 2, 2026

Copy link
Copy Markdown

Per #157728, this PR documents how exactly functions/methods in std::mpsc (and mpmc) block.

Copied from the issue:

For the wasm part of this specifically, yes, using a mutex anywhere is basically forbidden on the main thread in browsers. Personally I don't think it's reasonable to expect the standard library to use zero mutexes on wasm and make absolutely everything lock-free. This is a consequence of browsers and not something Rust can "just" fix. Basically I would not recommend changing the implementation and instead leaving it as-is. I'll note that there's a long and storied history of blocking-the-main-thread-with-wasm-threads in the browser, and I'm not putting in all the context here.

- alexcrichton

(P.S. documentation seems to be line wrapped but doesn't have a consistent wrapping width? I tried to match the surrounding style as best as I could; let me know if there's something better I should've done)

Fixes #157728

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 2, 2026
@rustbot

rustbot commented Jul 2, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @clarfonthey (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue
Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: @ChrisDenton, libs
  • @ChrisDenton, libs expanded to 13 candidates
  • Random selection from 6 candidates

Comment thread library/std/src/sync/mod.rs Outdated
//!
//! This is only of note to platforms which disallow blocking, such as multithreaded WebAssembly on the main thread.
//! None of the implementations in `std::sync` are guaranteed to be (or remain) non-blocking in this regard.
// Discussion on blocking: https://github.com/rust-lang/rust/issues/157728

@clarfonthey clarfonthey Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not 100% sure that linking a GitHub issue here is best, since we'd rather any new issues be brought up separately than just constantly going back to an issue that would eventually be closed. Is there any other information in that thread you feel might be useful to include here, since from what I can see, this should cover everything?

View changes since the review

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's fair. I thought it would be good to have a link back to the original decision (for posterity, I guess) but now that I think of it one could just find the issue through git blame...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's mostly just, I think that folks really wanting to dig into history can do that already, and we should be confident in changes we make unless we explicitly know they're temporary.

@clarfonthey

Copy link
Copy Markdown
Contributor

LGTM minus one minor comment on linking the GitHub issue, since this would close that issue.

@cyexclam cyexclam force-pushed the sync-document-blocking-guarantees branch from 1a54156 to 81a18e7 Compare July 6, 2026 17:36
@clarfonthey

Copy link
Copy Markdown
Contributor

@bors r+ rollup

@rust-bors

rust-bors Bot commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 81a18e7 has been approved by clarfonthey

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 6. This pull request will be tested once the tree is reopened.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 6, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jul 6, 2026
…arantees, r=clarfonthey

Document blocking guarantees for `std::sync`

Per rust-lang#157728, this PR documents how exactly functions/methods in `std::mpsc` (and `mpmc`) block.

Copied from the issue:
> For the wasm part of this specifically, yes, using a mutex anywhere is basically forbidden on the main thread in browsers. Personally I don't think it's reasonable to expect the standard library to use zero mutexes on wasm and make absolutely everything lock-free. This is a consequence of browsers and not something Rust can "just" fix. Basically I would not recommend changing the implementation and instead leaving it as-is. I'll note that there's a long and storied history of blocking-the-main-thread-with-wasm-threads in the browser, and I'm not putting in all the context here.
>
> \- alexcrichton

(P.S. documentation seems to be line wrapped but doesn't have a consistent wrapping width? I tried to match the surrounding style as best as I could; let me know if there's something better I should've done)

Fixes rust-lang#157728
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

std::sync::mpsc::Sender::send can block the current thread

3 participants