ACP: `Thread::os_id`

[tgross35]

Proposal

Problem statement

The Rust thread ID does not have any relation to OS thread IDs. The OS thread ID is what shows up in tools like ps and top (via /proc), debuggers, and various crash logs. It would be nice to have a way to make this value easily accessible, especially given that platform support is a mess (almost comically, every OS uses a slightly different name https://github.com/rust-lang/rust/blob/3507a749b365aae4eefa96ab700a9315d3280ee7/library/std/src/sys/pal/unix/thread.rs#L401-L455).

Motivating examples or use cases

This mostly supports tying logs from Rust programs to system logs.

Solution sketch

// std::thread

impl Thread {
    // On most platforms the ID is 32 bit and signed, but in practice nonnegative.
    fn os_id(&self) -> Option<u64>;
}

This returns the OS TID as a u64 if it could be determined, None if the platform does not support it. The documentation should mention that OS guarantees are weaker than for our ThreadId, the value may not be unique throughout process runtime.

The following platforms have support for some form of pthread_t -> pid_t:

• Android
• Apple
• Windows
• Glibc 2.42 (released only a month ago)

On these, the pthread_t can be stored in Thread and os_id can query an OS TID from that as needed. For everything else this will need a fallback that queries the current TID (much better supported) as part of thread startup code.

Alternatives

thread::current_os_id would also provide a way to get the OS TID. It would be more limited but the implementation is simpler.

Links and related work

• Some prior discussion starting at #t-libs > Printing thread ID on panic bikeshed @ 💬
• Me asking posix for a more sane way to do this https://www.mail-archive.com/austin-group-l@opengroup.org/msg13876.html

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[kennytm]

On these, the pthread_t can be stored in Thread and os_id can query an OS TID from that as needed.

The pthread_t is currently stored in the JoinHandle<T>, not the Thread. Can this os_id() method be added to JoinHandle<T> instead?

[tgross35]

The pthread_t is currently stored in the JoinHandle, not the Thread. Can this os_id() method be added to JoinHandle instead?

This wouldn't have a way to get the ID for the current thread without a separate method. Is there any reason not to move the pthread_t to the Thread? Since the JoinHandle contains Thread it can still access it.

[kennytm]

Is there any reason not to move the pthread_t to the Thread?

I suppose it is just separation of concern, as Thread contains no code that requires the native handle.

[Amanieu]

We discussed this in the @rust-lang/libs-api meeting and are happy to accept it (though the signature needs to be be fixed to take &self). However we made a few notes during the meeting:

• Thread cannot hold a pthread_t because the pthread_t becomes invalid once the thread is joined or detached. However Thread can outlive this because it is effectively an Arc.
• The documentation should warn that OS thread IDs may not be unique (PID wraparound can re-use IDs over the lifetime of the process).
• The documentation should warn that the OS ID may not be valid if the thread has exited, which can happen at any time. Except for the current thread's ID, the only safe use is for logging.

Please open a tracking issue and open a PR to rust-lang/rust to add it as an unstable feature. You can close this ACP once the tracking issue has been created.

[ibraheemdev]

We previously discussed stabilizing ThreadId::as_u64, and this was one of the things that came up as an alternative. Unlike an OS thread ID, std::thread::ThreadId guarantees lifetime uniqueness, and there was some pushback against guaranteeing a u64 representation.

thread::current_os_id would also provide a way to get the OS TID. It would be more limited but the implementation is simpler.

Why would it be more limited? Having to load a Thread is unnecessarily inefficient on platforms where the thread ID can be fetched directly.

[kennytm]

@ibraheemdev The point of getting the pid_t is because it "is what shows up in tools like ps and top (via /proc), debuggers, and various crash logs", ThreadId::as_u64 is completely useless for this ACP's purpose.

[ibraheemdev]

Sorry, I'm not suggesting that, I was just noting that having Thread::os_id or thread::current_os_id means we no longer need to stabilize ThreadId::as_u64.