Uh oh!
There was an error while loading. Please reload this page.
Add an unstable conversion from thread ID to u64 - #67566
Merged
Merged
Conversation
rust-highfive
commented
Dec 23, 2019
Contributor
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
Mark-Simulacrum
commented
Dec 23, 2019
MemberAuthor
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. |
pitdicker
commented
Dec 24, 2019
Contributor
I have wished for a method like this, 👍 |
cramertj
commented
Dec 26, 2019
Member
alexcrichton
approved these changes
Jan 6, 2020
alexcrichton
left a comment
Member
There was a problem hiding this comment.
Looks good to me! Want to open a tracking issue, set it up here, and then r=me?
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-Simulacrumforce-pushed
the
thread-id-u64
branch
from
January 6, 2020 15:56
4e7a541 to
d9a7db9CompareMark-Simulacrum
commented
Jan 6, 2020
MemberAuthor
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 |
bors
commented
Jan 6, 2020
Collaborator
📌 Commit d9a7db9 has been approved by |
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
This file contains hidden or 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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.