Uh oh!
There was an error while loading. Please reload this page.
std: use a mutex for ThreadId generation if available - #149476
Conversation
rustbot
commented
Nov 30, 2025
rustbot has assigned @Mark-Simulacrum. Use |
| #[cold] | ||
| fn exhausted() -> ! { | ||
| panic!("failed to generate unique thread ID: bitspace exhausted") | ||
| rtabort!("failed to generate unique thread ID: bitspace exhausted") |
There was a problem hiding this comment.
Panicking may allocate, so it shouldn't be used here either.
This violates the contract we established that the global allocator may call So if there's a platform without 64-bit atomics but which has an allocating |
joboet
commented
Nov 30, 2025
No it won't, the |
@joboet Actually, re-reading the code, neither If we were to adopt #147342 I think we might be able to get rid of the desperate path altogether. |
joboet
commented
Nov 30, 2025
The problem is that not all threads are spawned by Rust – and on foreign threads, it's the first call to |
orlp
commented
Nov 30, 2025
I hadn't considered foreign threads, you're right. |
This comment has been minimized.
This comment has been minimized.
RalfJung
commented
Nov 30, 2025
This still invokes |
| } | ||
| } | ||
| /// Generates a new unique thread ID. |
There was a problem hiding this comment.
| /// Generates a new unique thread ID. | |
| /// Generates a new unique thread ID. Might use the global allocator. |
ThreadId generation fallback path: avoid spurious yields Fixesrust-lang/miri#4737 Alternative to rust-lang#149476 Cc `@orlp` `@joboet`
ThreadId generation fallback path: avoid spurious yields Fixesrust-lang/miri#4737 Alternative to #149476 Cc `@orlp` `@joboet`
ThreadId generation fallback path: avoid spurious yields Fixesrust-lang/miri#4737 Alternative to #149476 Cc `@orlp` `@joboet`
ThreadId generation fallback path: avoid spurious yields Fixesrust-lang/miri#4737 Alternative to #149476 Cc `@orlp` `@joboet`
67c2ddd to
3c7ee48Comparerustbot
commented
Dec 2, 2025
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
rust-log-analyzer
commented
Dec 2, 2025
The job Click to see the possible cause of the failure (guessed by this bot) |
ThreadId generation fallback path: avoid spurious yields Fixes#4737 Alternative to rust-lang/rust#149476 Cc `@orlp` `@joboet`
joboet
commented
Dec 5, 2025
I don't think this really matters, closing. |
ThreadId generation fallback path: avoid spurious yields Fixesrust-lang/miri#4737 Alternative to rust-lang#149476 Cc `@orlp` `@joboet`
Fixesrust-lang/miri#4737
#144465 changed
ThreadId::newto use a spinlock on platforms without 64-bit atomics. This introduces subtle scheduling changes such as the one described in rust-lang/miri#4737 and isn't ideal from a performance perspective either. The necessity of avoidingMutexis not always given however – it only needs to be avoided if the thread handle is lazily initialised. For normal Rust threads however,stdgenerates the thread id inside the spawning logic, where allocation is expected. Thus this PR renames the currentThreadId::newtodesperate_newand reintroduces a versionThreadId::newthat employs aMutexto synchronise access to the inner spin-lock.CC @RalfJung@orlp