Tracking issue for getting pthread_t from JoinHandle

[alexcrichton]

This is a tracking issue for the thread_extensions feature in the standard library which allows acquiring a pthread_t from a JoinHandle on Unix. Some questions on this are:

• Should this trait also be implemented for Thread? (e.g. should we store the id there)
• Does it deserve its own trait or is a one-off JoinHandleExt ok?
• If you can get a pthread_t from a Thread can you also get a HANDLE from one on Windows?

[nagisa]

See #29461.

[alexcrichton]

This ended up not landing just yet, so closing for now, can reopen if it's resubmitted though.

[alexcrichton]

Gonna reopen with #30177 in the queue

[markuskobler]

Looks like JoinHandleExt exposes as_pthread_t or handle now but is there a reason for not implementing something similar on Thread itself?

[retep998]

The documentation for Thread says "A handle to a thread." however this is a complete lie. A Thread is nothing more than the name of the thread and a condition variable + mutex so it can unpark the thread. Since it doesn't actually have a handle to the thread it doesn't make any sense to implement those traits on Thread. That said as far as I can tell there isn't anything stopping Thread from having a handle to the thread.

[markuskobler]

Am I missing something obious. Is it not a case of exposing the following inner type with a ThreadExt?
https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/thread.rs#L155
or
https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/thread.rs#L81

[markuskobler]

Ignore me I understand the issue now. The use case I was after was something I thought would be as simple as thread::current().as_pthread_t() but I get the need for Thread using Arc now.

[nagisa]

@retep998 what our (representation of a) handle to a thread is, is up to us, not the operating system. As long as we’re capable of communicating to the OS’s threads, that is.

[retep998]

@nagisa The point was simply that std::thread::Thread currently does not store a handle to the OS thread , so it didn't make sense to implement those traits for std::thread::Thread as the current implementation doesn't have a OS thread handle to provide.

@markuskobler To get the current OS thread handle you can just use pthread_self or GetCurrentThread depending upon the platform.