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.

[alexcrichton]

🔔 This issue is now entering its cycle-long final comment period for tentative stabilization in 1.9 🔔

Some questions to consider as part of FCP:

• Can we may these lowerings available through std::thread::Thread?
• Can we somehow provide the ability to get the "current thread's OS handle"?

[retep998]

Providing this sort of API through Thread would be convenient. As far as I can tell the only two ways to get a Thread are via JoinHandle or thread::current, the former of which has a handle which can be duplicated, and the later can be retrieved with the functions mentioned earlier. Note that for GetCurrentThread the handle obtained from that would have to be duplicated in order to be stored in Thread as the returned value is merely a magic value that always refers to the current thread and is never closed.

[alexcrichton]

The libs team discussed this during triage yesterday and the decision was to stabilize what we have as-is. We are likely to add these methods in any scenario and we can always add the methods to Thread at a later date.