Clarify the guarantees that ThreadId does and doesn't make.

[ltratt]

The existing documentation does not spell out whether ThreadIds are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly, as it's a strong guarantee.

Examining the way ThreadIds are created also made me realise that the as_u64 method on ThreadId could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to ThreadId). I therefore think it's worth being even clearer that there's no relationship between the two.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

r? @joshtriplett as we'll want a T-libs FCP on the new guarantees, but there's also relevant discussion in #67939 which may make us want to avoid making additional guarantees.

[joshtriplett]

I thought, based on the previous discussion, that we'd landed on not making these guarantees, so that we could just use the OS thread ID?

[ltratt]

I think I'm still of the same mind on this issue as when I wrote #67939 (comment): it doesn't really matter what we choose to do, IMHO, so long as we change (at least) one of the code and documentation (on the basis that the status quo is going to lead people astray).

[joshtriplett]

I've found myself increasingly enamored of more robust techniques to make Rust's standard library not care what environment it's called from. As a result, I like the idea of using the OS thread ID where possible, rather than inventing our own.

[cuviper]

Put another way, if we allow the possibility of using OS thread IDs, then I don't think there's anything much that one can safely do with thread IDs in Rust

I see that not necessarily for users' sake, but for implementations to avoid their own atomic thread counter.

[danielhenrymantilla]

Worthy of consideration:

• https://lib.rs/crates/send_wrapper
• https://lib.rs/crates/diplomatic-bag

are two crates which rely on ThreadId unicity to be sound. I know I've personally written code that makes that assumption in the past, for experimental crates or whatnot which I didn't publish to crates.io.

---

All this to say that:

• ThreadId not being unique during the lifetime of a process is a footgun for those that may not be aware of this; a soundness-endangering one!
• it could lead to "reuse" race conditions such as those for pids on Unix;
• the solution is simple to implement / circumvent, see dtolnay/syn@964cd08 for an example of this.

This means that if the std library does not guarantee this, the ecosystem will be split between people unaware of the issue doing The Wrong Thing™, and people reimplementing it themselves, inefficiently for OSes that actually gave stronger guarantees, and redundantly in between implementations, and even potentially incorrectly w.r.t. overflows.

The standard library, on the other hand, to guarantee this, would just need a fallback module for this implementation, written once and correctly, that would only be pulled for the platforms unable to feature something better.

So, while I respect the idea of reducing the maintenance burden for the standard library by not requiring cfg-gated modules to meet these criteria, efficiently for the OSes that support it, and semantically correctly for the others, @joshtriplett, I do think the situation, for this very issue, is worthy of exceptional treatment.

• (Or, as a fallback, a nursery crate to provide a canonical "lib" implementation)

[joshtriplett]

We discussed this again in today's @rust-lang/libs-api meeting. I decided to withdraw my objection, since you can only get the ID for a random non-Rust thread via thread::current, and we already have things like thread names that require thread-local storage (at least for lazy initialization).

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[m-ou-se]

Suggested change

	/// be reused, even if a thread dies. `ThreadId`s are under the control of
	/// be reused, even after thread terminates. `ThreadId`s are under the control of

[ltratt]

I've used a minor variant of this in d66a9e1.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[dtolnay]

@bors r+ rollup

[bors]

📌 Commit d66a9e1 has been approved by dtolnay