Tracking Issue for `Thread::{into_raw, from_raw}`

[ibraheemdev]

Feature gate: #![feature(thread_raw)]

This is a tracking issue for Thread::into_raw and Thread::from_raw.

These functions allow conversions between a Thread and a raw pointer, which is useful in concurrent code as it allows storing a Thread in an AtomicPtr.

Public API

// std::thread

impl Thread {
    fn into_raw(self) -> *const ();
    unsafe fn from_raw(ptr: *const ()) -> Thread;    
}

Steps / History

• ACP: ACP: add Thread::into_raw and Thread::from_raw libs-team#200
• Implementation: Add Thread::{into_raw, from_raw} #97524
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Do we want to commit to guaranteeing that Thread can always be represented as a pointer/integer?

[yanchith]

Not sure If I am missing something, but into_raw requires the thread by value, and that is not always available. E.g. JoinHandle::thread only gives out a shared reference.

How can I unpark a thread for which I just have a JoinHandle?

[ibraheemdev]

@yanchith Thread is cloneable, but it might make sense to have a as_raw method as well.

[yanchith]

Yeah, thanks! I didn't notice Thread was Clone. I am perfectly happy with that now.

Thread::as_raw: sure, if it can be designed such that the data inside the Arc inside Thread doesn't get dropped meanwhile. Thread::into_inner leaks the Arc, so that's taken care of.

[zesterer]

As a point of interest: is it legal to use Thread::from_raw if the pointer is shared in a multi-threaded context? A lot of code assumes this to be true for Arc::from_raw, and of course the implementation uses an Arc, but it is non-obvious.

Use of Thread::from_raw in a multi-threaded context might result in two Threads existing that both point to the same block of memory, but with the strong count still being 1 (even if momentarily).

An API like fn Thread::from_raw_ref(ptr: *const ()) -> &Thread would make it much easier to use this API correctly (and avoid a lot of error-prone core::mem::forget in referential contexts to boot). With Arc, this is already trivially possible since the pointer you get back is a *const T, but here we only get a *const () so you can't even temporarily turn it into a reference to the original Thread.

[orlp]

@zesterer It's fairly obvious to me that it's unsound to call Thread::from_raw twice in an unsynchronized manner if one of them can drop the value in the meantime. I personally don't think the from_raw_ref API is necessary, and it would still be dangerous if someone calls from_raw_ref at the same time as someone else calls from_raw.

Regarding the unresolved question,

Do we want to commit to guaranteeing that Thread can always be represented as a pointer/integer?

This API inherently guarantees that the Thread can be represented as a pointer.

I fail to see any reason why we would guarantee that pointer could be converted to/from an integer outside of the usual expose_provenance / with_exposed_provenance rules which are already valid today. If that would really be desired it could also be added later.

---

I personally don't see anything that's blocking this for a FCP / stabilization. Could we move along with that?