Tracking issue for std::thread::ThreadId #21507

aldanor · 2015-01-22T12:00:59Z

Update description

Tracking issue for std::thread::ThreadId. Points to consider when stabilizing:

Implementation of a mutex + u64, unconditional panic if space is exhausted
Various traits on ThreadId, including Copy

Original report

Not sure if it can be considered as bug but it sure cripples the existing threading API (e.g., makes it harder for a thread to identify itself or store/pass its identity).

// it could also be nice if Thread was able to return a unique integer id() (or hash itself?..).

The text was updated successfully, but these errors were encountered:

murarth · 2015-08-26T20:12:54Z

I'd also like to have Eq implemented for Thread. Would a PR be accepted to this effect or would it require an RFC?

remram44 · 2015-10-27T23:26:52Z

I'd very much like some kind of thread id, I'm pretty sure every Thread implementation around gives numeric ids (Python has a string name much like Rust but also offers Thread.ident, "a nonzero integer").

frewsxcv · 2016-03-20T00:19:38Z

FYI, here's the associated issue in the RFCs repo: rust-lang/rfcs#1435

Add ThreadId for comparing threads This adds the capability to store and compare threads with the current calling thread via a new struct, `std::thread::ThreadId`. Addresses the need outlined in issue #21507. This avoids the need to add any special checks to the existing thread structs and does not rely on the system to provide an identifier for a thread, since it seems that this approach is unreliable and undesirable. Instead, this simply uses a lazily-created, thread-local `usize` whose value is copied from a global atomic counter. The code should be simple enough that it should be as much reliable as the `#[thread_local]` attribute it uses (however much that is). `ThreadId`s can be compared directly for equality and have copy semantics. Also see these other attempts: - #29457 - #29448 - #29447 And this in the RFC repo: rust-lang/rfcs#1435

ticki · 2017-02-03T22:34:10Z

I think it would be fitting to implement Hash, like std::mem::Discriminant, which doesn't expose an actual value either.

nrc · 2017-04-02T09:49:13Z

Just to chime in here, it would be really nice to have a proper Debug impl - I have a multi-threaded program I'm trying to debug and I'm trying to work out which threads are hitting a certain bit of code. Doing a println with current::id() would be really easy, but I can't and there isn't a nice way to get around this afaikt (will end up transmuting of course).

frewsxcv · 2017-04-02T14:08:27Z

There's a PR open to implement Hash for ThreadId: #41008

sfackler · 2017-04-02T19:36:43Z

@nrc that seems reasonable to me. I asked the author of #41008 to add that derive as well.

Derive Hash for ThreadId + better example Derive `Hash` for `ThreadId` (see comments in rust-lang#21507). Useful for making maps based on thread, e.g. `HashMap<ThreadId, ?>`. Also update example code for thread IDs to be more useful.

Derive Hash for ThreadId + better example Derive `Hash` for `ThreadId` (see comments in #21507). Useful for making maps based on thread, e.g. `HashMap<ThreadId, ?>`. Also update example code for thread IDs to be more useful.

aturon · 2017-05-11T21:22:19Z

@rust-lang/libs, thoughts on stabilization?

alexcrichton · 2017-05-11T22:01:19Z

@aturon some might say you could even canvas opinions through...

@rfcbot fcp merge

rfcbot · 2017-05-11T22:58:26Z

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

dtolnay · 2017-05-12T00:56:23Z

BTreeMap wants to know whether we could get an impl Ord for ThreadId. Are there any reasons not to have one?

cuviper · 2017-05-12T01:22:20Z

Ord is uncomfortable to me. For instance, people might observe that the IDs sort in order of creation, but do we want to promise that?

alexcrichton · 2017-05-12T15:26:24Z

I'd personally go either way on Ord, I don't mind starting out conservatively and I also wouldn't mind adding it. If we do add it I'd at least want to clearly document "you really shouldn't rely on orderings between thread ids, just that you can order them to deduplicate"

sfackler · 2017-05-16T03:40:34Z

I'm not super concerned about the Ord impl. We certainly don't want to promise that IDs sort in order of creation - TIDs on Unix systems wrap around pretty frequently.

cuviper · 2017-05-16T03:49:56Z

FWIW, in the current implementation it's a monotonic u64 counter, with no relationship to the OS TID at all. So it will in fact sort in the order of creation, or the order when first seen for threads created outside of Rust. But I still wouldn't want to promise this.

dlight · 2017-05-16T06:45:05Z

If ThreadId is going to implement Ord, it probably makes sense to implement Hash too.

sagebind · 2017-05-16T14:17:44Z

@dlight Currently, it already implements Hash.

I don't see an issue with implementing Ord, so long as we warn in the docs that the sort order doesn't indicate anything about the Threads they correspond to.

The only issue I see is if we change the implementation later down the road to use system handles, it would be difficult to provide a stable Ord implementation (e.g. there's no pthread_cmp(), only pthread_equal()).

sfackler · 2017-05-16T15:52:37Z

We wouldn't be able to implement Hash for system handles anyway, so I think that ship has probably sailed.

cuviper · 2017-05-16T15:56:19Z

System handles also aren't globally unique when threads stop and new ones start. Is that a property we want to guarantee about ThreadId?

sagebind · 2017-05-16T17:07:26Z

We wouldn't be able to implement Hash for system handles anyway, so I think that ship has probably sailed.

That's a good point. I think that's why we chose not to use system handles in the first place: it makes ThreadId much harder to use and less useful.

@cuviper We don't currently make such a guarantee (which should reflect in the docs), but I think we should guarantee globally unique IDs. Assuming we don't plan on changing the IDs from being a custom integer. If the range of IDs becomes a problem, it is easy enough to increase the number of bits being used and maintain that guarantee.

rfcbot · 2017-05-23T20:44:23Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2017-06-02T20:58:36Z

The final comment period is now complete.

Closes rust-lang#21507

sfackler added the A-libs label Jan 22, 2015

This was referenced Oct 29, 2015

Implement Eq for Thread #29447

Closed

Add a numeric ID to threads #29448

Closed

nagisa mentioned this issue Dec 29, 2015

Make it possible to compare threads rust-lang/rfcs#1435

Closed

sagebind mentioned this issue Sep 8, 2016

Add ThreadId for comparing threads #36341

Merged

alexcrichton added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. labels Oct 9, 2016

alexcrichton changed the title ~~PartialEq not implemented for std::thread::Thread~~ Tracking issue for std::thread::ThreadId Oct 9, 2016

steveklabnik removed the A-libs label Mar 24, 2017

sagebind mentioned this issue Apr 2, 2017

Derive Hash for ThreadId + better example #41008

Merged

rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label May 23, 2017

bors closed this as completed in dc411e3 Jun 28, 2017

brson pushed a commit to brson/rust that referenced this issue Jul 8, 2017

Stabilize ThreadId

0dfe6da

Closes rust-lang#21507

alexcrichton pushed a commit to brson/rust that referenced this issue Jul 13, 2017

Stabilize ThreadId

647df67

Closes rust-lang#21507

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for std::thread::ThreadId #21507

Tracking issue for std::thread::ThreadId #21507

aldanor commented Jan 22, 2015 •

edited by alexcrichton

Loading

murarth commented Aug 26, 2015

remram44 commented Oct 27, 2015

frewsxcv commented Mar 20, 2016

ticki commented Feb 3, 2017

nrc commented Apr 2, 2017

frewsxcv commented Apr 2, 2017

sfackler commented Apr 2, 2017

aturon commented May 11, 2017

alexcrichton commented May 11, 2017

rfcbot commented May 11, 2017 •

edited by Kimundi

Loading

dtolnay commented May 12, 2017

cuviper commented May 12, 2017

alexcrichton commented May 12, 2017

sfackler commented May 16, 2017

cuviper commented May 16, 2017

dlight commented May 16, 2017

sagebind commented May 16, 2017

sfackler commented May 16, 2017

cuviper commented May 16, 2017

sagebind commented May 16, 2017

rfcbot commented May 23, 2017

rfcbot commented Jun 2, 2017

Tracking issue for std::thread::ThreadId #21507

Tracking issue for std::thread::ThreadId #21507

Comments

aldanor commented Jan 22, 2015 • edited by alexcrichton Loading

Update description

Original report

murarth commented Aug 26, 2015

remram44 commented Oct 27, 2015

frewsxcv commented Mar 20, 2016

ticki commented Feb 3, 2017

nrc commented Apr 2, 2017

frewsxcv commented Apr 2, 2017

sfackler commented Apr 2, 2017

aturon commented May 11, 2017

alexcrichton commented May 11, 2017

rfcbot commented May 11, 2017 • edited by Kimundi Loading

dtolnay commented May 12, 2017

cuviper commented May 12, 2017

alexcrichton commented May 12, 2017

sfackler commented May 16, 2017

cuviper commented May 16, 2017

dlight commented May 16, 2017

sagebind commented May 16, 2017

sfackler commented May 16, 2017

cuviper commented May 16, 2017

sagebind commented May 16, 2017

rfcbot commented May 23, 2017

rfcbot commented Jun 2, 2017

aldanor commented Jan 22, 2015 •

edited by alexcrichton

Loading

rfcbot commented May 11, 2017 •

edited by Kimundi

Loading