Tracking Issue for thread_os_id

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: rust-lang/libs-team#635
• Implementation: #160219
• Final comment period (FCP)^1
• 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 https://github.com/rust-lang/rust/issues/160215#issuecomment-5145105691: thread::current_os_id can be useful but is less flexible, so we can consider it separately.

Start with the std:🧵:Thread::os_id API, the implementation in #160219, and the ACP in rust-lang/libs-team#635. Review the unresolved question about None for threads that have not started, then confirm the intended semantics and determine the remaining FCP and stabilization steps.