Implement Thread::os_id

[valentynkit]

Implements Thread::os_id as an unstable feature, per the accepted ACP rust-lang/libs-team#635.

Tracking issue: #160215

It returns the OS-level thread id, the one that shows up in tools like ps and top, debuggers, and crash logs. ThreadId has no guaranteed relationship to it.

Most of the work is already in tree: sys::thread::current_os_id was added for the thread id in the panic message. This adds a field to hold the value and the public accessor.

Implementation

Per the meeting notes on the ACP, Thread does not store a pthread_t, since that goes invalid on join or detach while the handle outlives it. The id is captured while the thread runs instead. The two documentation warnings the notes asked for are on the method.

Thread::new has three callers. init_current and current_or_unnamed run on the thread being described, so they fill the id immediately. spawn_unchecked runs on the spawning thread before the child exists, so the child fills it in ThreadInit::init before any user code runs. The field is therefore written after the handle already exists and read from other threads, and a handle whose thread has not started yet reports None.

The field is a OnceLock<u64>. An atomic would need a sentinel for "not yet known", which nothing guarantees an OS id cannot collide with, and a cfg_select for the targets without 64-bit atomics. OnceLock needs neither.

Testing

On aarch64-apple-darwin:

• ./x check library
• ./x test library/std --no-doc --test-args thread_os_id, 3 passed (the two new ones and the existing test_thread_os_id_not_equal)
• ./x test library/std --doc --test-args os_id, 1 passed
• ./x fmt --all leaves the diff unchanged

The non-Apple arms of current_os_id do not compile on the host, so CI is the check for those.

r? libs

[joboet]

Nothing guarantees that the OS's ID is non-zero, we really shouldn't use zero as a sentinel.

View changes since the review

[valentynkit]

Switched to OnceLock: write-once without a sentinel, and it needs no 64-bit atomic so the cfg_select is gone too.

Waiting would need the child to always store the value, so OnceLock<Option>.
I'm also not sure how it works out for spawn hooks, which get &Thread on the parent before the thread exists.
You mentioned you have an implementation, so if you've already worked that out I'd rather build on it than guess.

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[valentynkit]

@rustbot ready

[joboet]

A meta comment: I appreciate your recent contributions to the project, you are clearly interested in helping out and invest time and thought into it. At the same time, especially the description of this PR makes it very obvious that you are using a LLM to aid you in your contributions, both in writing code and comments. These kinds of cases have been very intensely discussed within the project, and the result of that discussion is our LLM policy that will come into effect next week. Under that policy your LLM usage is deemed forbidden, and failing to declare it (like you have been doing) may result in moderation actions against you.

I'm not a moderator, and this is not a moderation warning, just some friendly advice that I want to give you, stemming from years of working on the standard library:

In my experience, the hard part about working on the standard library is not actually writing the code, but in

1. Doing the research and taking the thinking time to verify that the changes are truly correct. The standard library ships on literally billions of devices, we must try very hard to ensure that it works as intended.
2. Communicating that work to other people so that not just you, but the person reviewing your work (in this case, me) and everyone else can follow along.

An LLM can do neither those things. While they are admittedly good at doing the mechanical task of writing the code, they are awfully unreliable when it comes to providing evidence, have little to no intrinsic capability to exercise good judgement and are fundamentally just not you.

As an example, the current description of this PR is mostly just a very detailed summary of its changes. I can see those myself, thank you very much, that's what the "Files changed" tab is for! The much more interesting questions in this case are e.g. why OnceLock is correct in this case (both you and me need to think this through in any case, the LLM cannot lift that responsibility off our shoulders), or how one might do better (here you'd need e.g. links to platform documentation – which is rather difficult for an LLM to find especially in the curious case of pthread_gettid_np), or why this PR is still a good point to start from (that's a matter of taste and opinion, I see why one might argue that it is). And if you've thought about all these questions, then writing these kinds of PRs entirely on your own is actually easier than proofreading the LLMs output and explaining all your thoughts to it.

Thus, please, remember to take time to think and research and be the author, not just the editor, of your communication and your code. If you want to learn how best to use (or not use) LLMs, feel free to join our LLM-mentoring channel on Zulip.

As for me, I'm not interested in some stochastic parrot's output, but in other people's, since that's what I learn and thrive from. That's why I invest my time in this project anyway, and am very happy to help other people out if they get stuck. I must insist however that the responsibility of doing the thinking and research doesn't fall on my shoulders alone.

@rustbot author
until you update the PR description with something entirely of your own.

[valentynkit]

In my experience, the hard part about working on the standard library is not actually writing the code, but in

1. Doing the research and taking the thinking time to verify that the changes are truly correct. The standard library ships on literally _billions_ of devices, we must try very hard to ensure that it works as intended.

2. Communicating that work to other people so that not just you, but the person reviewing your work (in this case, me) and everyone else can follow along.

Thanks for your advice, I totally agree with inappropriate use of LLM in this PR, I usually trying to take more time preparing the PR and understanding all the nuances, this one was bad and too heavily relied on AI.

Thanks and I will take it into consideration.

As for this PR, I will take some time to really reason about it and also consider other approaches.
Especially about using OnceLock or alternative approaches.

Sorry for that. :)

[tgross35]

Could this do the assert_ne! test here? I think that demos relevant properties a bit better.

View changes since the review

[tgross35]

It's usable for any thread that is running, not just the current right?

I think the property to convey is that OS TIDs uniquely represent a thread among other running threads, which effectively means that if a thread isn't known to be running then ID can only be used in cases where non-uniqueness is okay (e.g. logging). And then one way to know the thread is running is if you're looking at the current thread's ID.

Not sure how best to put this into words.

View changes since the review

[teor2345]

Some sandboxes or containers allow per-function filtering, so it is also possible the thread ID exists with an API to read it, but the process can't do that.

Suggested change

	/// it. `None` means the platform has no such id or offers no way to read it,
	/// it. `None` means the platform has no such id or it can't be read,

View changes since the review

[Darksonn]

Why doesn't Thread::new just call set_os_id_to_current internally?

If there are callers where this doesn't work, maybe we should have two constructors?

• Thread::new_current uses current OS id
• Thread::new_remote takes OS id as paramter

I think this would also avoid the OnceLock.

View changes since the review