Make Option<ThreadId> no larger than ThreadId, with NonZeroU64 #59291
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
| @@ -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.
Out of interest, is there any reason we don't use an atomicu64 here instead?
There was a problem hiding this comment.
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.
@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.
@sanmai-NL have you profiled and seen this as a problem?
There was a problem hiding this comment.
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.
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.
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 |
sanxiyn
added
S-waiting-on-author
|
@bors: r+ |
|
📌 Commit c1d9191 has been approved by |
bors
added
S-waiting-on-bors
…xcrichton Make Option<ThreadId> no larger than ThreadId, with NonZeroU64
…xcrichton Make Option<ThreadId> no larger than ThreadId, with NonZeroU64
Rollup of 18 pull requests Successful merges: - #59106 (Add peer_addr function to UdpSocket) - #59170 (Add const generics to rustdoc) - #59172 (Update and clean up several parts of CONTRIBUTING.md) - #59190 (consistent naming for Rhs type parameter in libcore/ops) - #59236 (Rename miri component to miri-preview) - #59266 (Do not complain about non-existing fields after parse recovery) - #59273 (some small HIR doc improvements) - #59291 (Make Option<ThreadId> no larger than ThreadId, with NonZeroU64) - #59297 (convert field/method confusion help to suggestions) - #59304 (Move some bench tests back from libtest) - #59309 (Add messages for different verbosity levels. Output copy actions.) - #59321 (Unify E0109, E0110 and E0111) - #59322 (Tweak incorrect escaped char diagnostic) - #59323 (use suggestions for "enum instead of variant" error) - #59327 (Add NAN test to docs) - #59329 (cleanup: Remove compile-fail-fulldeps directory again) - #59347 (Move one test from run-make-fulldeps to ui) - #59360 (Add tracking issue number for `seek_convenience`) Failed merges: r? @ghost
No description provided.