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

std: allow after-main use of synchronization primitives #132730

Merged
merged 1 commit into from
Nov 25, 2024

Conversation

joboet
Copy link
Member

@joboet joboet commented Nov 7, 2024

By creating an unnamed thread handle when the actual one has already been destroyed, synchronization primitives using thread parking can be used even outside the Rust runtime.

This also fixes an inefficiency in the queue-based RwLock: if thread::current was not initialized yet, it will create a new handle on every parking attempt without initializing thread::current. The private current_or_unnamed function introduced here fixes this.

@rustbot
Copy link
Collaborator

rustbot commented Nov 7, 2024

r? @Noratrieb

rustbot has assigned @Noratrieb.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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 Nov 7, 2024
@bors
Copy link
Contributor

bors commented Nov 18, 2024

☔ The latest upstream changes (presumably #128219) made this pull request unmergeable. Please resolve the merge conflicts.

By creating an unnamed thread handle when the actual one has already been destroyed, synchronization primitives using thread parking can be used even outside the Rust runtime.

This also fixes an inefficiency in the queue-based `RwLock`: if `thread::current` was not initialized yet, it will create a new handle on every parking attempt without initializing `thread::current`. The private `current_or_unnamed` function introduced here fixes this.
@Noratrieb
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Nov 24, 2024

📌 Commit 5a856b8 has been approved by Noratrieb

It is now in the queue for this repository.

@bors bors 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 Nov 24, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 24, 2024
Rollup of 6 pull requests

Successful merges:

 - rust-lang#132730 (std: allow after-main use of synchronization primitives)
 - rust-lang#133105 (only store valid proc macro item for doc link)
 - rust-lang#133260 (Constify the `Deref`/`DerefMut` traits, too)
 - rust-lang#133297 (Remove legacy bitcode for iOS)
 - rust-lang#133298 (Mention that std::fs::remove_dir_all fails on files)
 - rust-lang#133384 (add a test for target-feature-ABI warnings in closures and when calling extern fn)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 31b4023 into rust-lang:master Nov 25, 2024
6 checks passed
@rustbot rustbot added this to the 1.85.0 milestone Nov 25, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 25, 2024
Rollup merge of rust-lang#132730 - joboet:after_main_sync, r=Noratrieb

std: allow after-main use of synchronization primitives

By creating an unnamed thread handle when the actual one has already been destroyed, synchronization primitives using thread parking can be used even outside the Rust runtime.

This also fixes an inefficiency in the queue-based `RwLock`: if `thread::current` was not initialized yet, it will create a new handle on every parking attempt without initializing `thread::current`. The private `current_or_unnamed` function introduced here fixes this.
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.

4 participants