Add an unstable conversion from thread ID to u64 #67566
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
It is intended for this to close #52780, though it is not mutually exclusive with it. I am against adding a direct Display impl for ThreadId (there is not "one true way" that I would expect it to be formatted); this allows an easy way to get the "just a number" formatting for ThreadId that seems to be commonly wanted. |
|
I have wished for a method like this, 👍 |
Mark-Simulacrum
added
the
T-libs-api
alexcrichton
approved these changes
Jan 6, 2020
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).
Mark-Simulacrum
force-pushed
the
thread-id-u64
branch
from
4e7a541 to
d9a7db9
Compare
|
Updated with a tracking issue and also added a bit of text even further warning against using the returned value for non-equality (specifically, ordering not being defined). @bors r=alexcrichton |
|
📌 Commit d9a7db9 has been approved by |
bors
added
S-waiting-on-bors
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Jan 6, 2020
…excrichton 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). I will file a tracking issue as soon as this is loosely approved.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Jan 7, 2020
…excrichton 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). I will file a tracking issue as soon as this is loosely approved.
bors
added a commit
that referenced
this pull request
Jan 7, 2020
Rollup of 13 pull requests Successful merges: - #67566 (Add an unstable conversion from thread ID to u64) - #67671 (Account for `type X = impl Trait;` in lifetime suggestion) - #67727 (Stabilise vec::remove_item) - #67877 (Omit underscore constants from rustdoc) - #67880 (Handle multiple error fix suggestions carefuly) - #67898 (Improve hygiene of `newtype_index`) - #67908 (rustdoc: HTML escape const values) - #67909 (Fix ICE in const pretty printing and resolve FIXME) - #67929 (Formatting an example for method Vec.retain) - #67934 (Clean up E0178 explanation) - #67936 (fire "non_camel_case_types" for associated types) - #67943 (Missing module std in example.) - #67962 (Update books) Failed merges: r? @ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).
I will file a tracking issue as soon as this is loosely approved.