Tracking Issue for thread_os_id

[valentynkit]

Feature gate: #![feature(thread_os_id)]

This is a tracking issue for Thread::os_id, which returns the OS-level thread id of the thread a handle refers to. That is the id that shows up in tools like ps and top, debuggers, and crash logs. ThreadId is under the control of the standard library and has no guaranteed relationship to it, so the two cannot be used interchangeably.

Public API

// std::thread

impl Thread {
    pub fn os_id(&self) -> Option<u64>;
}

None means the platform has no OS thread id, or has no way to read it, or the handle belongs to a spawned thread that has not started running yet. That last case is not one of the reasons the ACP gave, so it is an unresolved question below.

Steps / History

• ACP: ACP: Thread::os_id libs-team#635
• Implementation: Implement Thread::os_id #160219
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• A handle for a spawned thread exists before the thread does, and the implementation has the thread record its own id once it starts running, so until then os_id returns None. The ACP describes None as meaning "the platform does not support it", so this is an extra reason a caller can see it. As far as I can tell that is fine for an unstable feature, but worth confirming before stabilization.
• The ACP listed a free thread::current_os_id under alternatives, and the question of why that would be "more limited", given that "having to load a Thread is unnecessarily inefficient on platforms where the thread ID can be fetched directly", was left unanswered. std::thread does have an internal current_os_id, but it returns u64 and falls back to the Rust thread id, so it is not the shape a public function would want. Out of scope here either way, but still open.
  • Resolving based on Tracking Issue for thread_os_id #160215 (comment): thread::current_os_id can be useful but is less flexible, so we can consider it separately.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[joboet]

• A handle for a spawned thread exists before the thread does, and the implementation has the thread record its own id once it starts running, so until then os_id returns None. The ACP describes None as meaning "the platform does not support it", so this is an extra reason a caller can see it. As far as I can tell that is fine for an unstable feature, but worth confirming before stabilization.

You could use OnceLock::wait to wait until the thread has stored the ID on the platforms that don't have a way to query the thread ID of a spawned thread (for those, you can do initialisation in both the spawning and spawned thread, so that the ID is accessible as soon as the thread handle is).

I have been working on an implementation of this, but feel free to claim this yourself.

[valentynkit]

You could use OnceLock::wait

Didn't see this until after I'd opened the PR, sorry. :)

[zachs18]

The ACP listed a free thread::current_os_id under alternatives, and the question of why that would be "more limited", given that "having to load a Thread is unnecessarily inefficient on platforms where the thread ID can be fetched directly", was left unanswered.

I think std::thread::current_os_id is orthogonal to Thread::os_id; you could not (easily) use std::thread::current_os_id to get the OS id of a non-current thread that you have a Thread handle to. I do think std::thread::current_os_id could be useful in addition to Thread::os_id though, to avoid loading the current thread's Thread if you just need the current thread's OS id.

[valentynkit]

You could use OnceLock::wait to wait until the thread has stored the ID on the platforms that don't have a way to query the thread ID of a spawned thread (for those, you can do initialisation in both the spawning and spawned thread, so that the ID is accessible as soon as the thread handle is).

I have been working on an implementation of this, but feel free to claim this yourself.

I have walked through it, and I agree with the double-sided init: the parent fills the id right after creating the thread on platforms that have a by-handle query, and the child fills it at start as it does in the current PR. Apple's pthread_threadid_np is already in rust libc.
But missing for linux and other platforms.
pthread_gettid_np was added in glibc 2.42+.

On OnceLock::wait I'd still keep None. Where a by-handle query exists the wait is never reached, and where it doesn't there is no parent side, so it degrades to "block until the child gets scheduled".

I think returning None is safer as fallback rather than blocking, also some targets return always None from imp::current_os_id() even when child ask for it, there a waiter would never wake (or having logic per platform for this) so we still need to have None case anyway.

So in this PR None means either the platform has no OS id at all, or the thread hasn't started yet. Returning that seems safer than blocking, unless I'm missing a motivation for it.