Repository navigation
Tracking Issue for Thread::{into_raw, from_raw} #97523
Description
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_rawandThread::from_rawlibs-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
Threadcan always be represented as a pointer/integer?
Reacted by Joshua Barretto
Reacted by kennytm
Activity
yanchith commentedon Feb 7, 2025
Not sure If I am missing something, but
into_rawrequires the thread by value, and that is not always available. E.g.JoinHandle::threadonly gives out a shared reference.How can I unpark a thread for which I just have a JoinHandle?
ibraheemdev commentedon Feb 7, 2025
@yanchith
Threadis cloneable, but it might make sense to have aas_rawmethod as well.yanchith commentedon Feb 9, 2025
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_innerleaks the Arc, so that's taken care of.zesterer commentedon May 25, 2025
As a point of interest: is it legal to use
Thread::from_rawif the pointer is shared in a multi-threaded context? A lot of code assumes this to be true forArc::from_raw, and of course the implementation uses anArc, but it is non-obvious.Use of
Thread::from_rawin a multi-threaded context might result in twoThreads 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 ()) -> &Threadwould make it much easier to use this API correctly (and avoid a lot of error-pronecore::mem::forgetin referential contexts to boot). WithArc, 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 originalThread.orlp commentedon Dec 20, 2025
@zesterer It's fairly obvious to me that it's unsound to call
Thread::from_rawtwice in an unsynchronized manner if one of them can drop the value in the meantime. I personally don't think thefrom_raw_refAPI is necessary, and it would still be dangerous if someone callsfrom_raw_refat the same time as someone else callsfrom_raw.Regarding the unresolved question,
This API inherently guarantees that the
Threadcan 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_provenancerules 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?