From d9a7db901e33940cb2ccda6afe21b9916e66d9d2 Mon Sep 17 00:00:00 2001 From: Mark Rousskov Date: Mon, 23 Dec 2019 12:54:54 -0500 Subject: [PATCH] Add an unstable conversion from thread ID to u64 We see multiple cases inside rustc and ecosystem code where ThreadId is transmuted to u64, exploiting the underlying detail. This is suboptimal (can break unexpectedly if we change things in std). It is unlikely that ThreadId will ever need to be larger than u64 -- creating even 2^32 threads over the course of a program is quite hard, 2^64 is even harder. As such, we do not choose to return a larger sized type (e.g. u128). If we choose to shrink ThreadId in the future, or otherwise change its internals, it is likely that a mapping to u64 will still be applicable (though may become more complex). --- src/libstd/thread/mod.rs | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/libstd/thread/mod.rs b/src/libstd/thread/mod.rs index b17418911380d..0dc43c7e6510a 100644 --- a/src/libstd/thread/mod.rs +++ b/src/libstd/thread/mod.rs @@ -1072,6 +1072,19 @@ impl ThreadId { ThreadId(NonZeroU64::new(id).unwrap()) } } + + /// This returns a numeric identifier for the thread identified by this + /// `ThreadId`. + /// + /// As noted in the documentation for the type itself, it is essentially an + /// opaque ID, but is guaranteed to be unique for each thread. The returned + /// value is entirely opaque -- only equality testing is stable. Note that + /// it is not guaranteed which values new threads will return, and this may + /// change across Rust versions. + #[unstable(feature = "thread_id_value", issue = "67939")] + pub fn as_u64(&self) -> u64 { + self.0.get() + } } ////////////////////////////////////////////////////////////////////////////////