-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Make Option<ThreadId> no larger than ThreadId, with NonZeroU64 #59291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
@@ -1036,15 +1037,15 @@ pub fn park_timeout(dur: Duration) { | |||
/// [`Thread`]: ../../std/thread/struct.Thread.html | |||
#[stable(feature = "thread_id", since = "1.19.0")] | |||
#[derive(Eq, PartialEq, Clone, Copy, Hash, Debug)] | |||
pub struct ThreadId(u64); | |||
pub struct ThreadId(NonZeroU64); | |||
|
|||
impl ThreadId { | |||
// Generate a new unique thread ID. | |||
fn new() -> ThreadId { | |||
// We never call `GUARD.init()`, so it is UB to attempt to | |||
// acquire this mutex reentrantly! | |||
static GUARD: mutex::Mutex = mutex::Mutex::new(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of interest, is there any reason we don't use an atomicu64 here instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a mutex is slightly more portable than an AtomicU64
, and this isn't really perf critical so we didn't need to reach for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexcrichton: At @Structure-Systems we're logging thread IDs at a high frequency. How does this design decision impact performance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sanmai-NL have you profiled and seen this as a problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mutex is only locked when a thread is created, not when its thread id is read, FYI.
@@ -1036,15 +1037,15 @@ pub fn park_timeout(dur: Duration) { | |||
/// [`Thread`]: ../../std/thread/struct.Thread.html | |||
#[stable(feature = "thread_id", since = "1.19.0")] | |||
#[derive(Eq, PartialEq, Clone, Copy, Hash, Debug)] | |||
pub struct ThreadId(u64); | |||
pub struct ThreadId(NonZeroU64); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to allow more aggressive niche optimizations you can also reserve a few (thousand?) values at the end of the value range via #[rustc_layout_scalar_valid_range_end(0xFFFF_FFFF_FFFF_0000)]
(that will require unsafe code though)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m a bit wary of adding more use of rustc_layout_scalar_valid_range_end
when there seems to be no plan to ever stabilize it. And I don’t know how common are cases when this would make a difference over non-zero.
Thanks @SimonSapin! r=me if you add a test as well asserting that |
@bors: r+ |
📌 Commit c1d9191 has been approved by |
No description provided.