Tracking issue for std::thread::ThreadId

[aldanor]

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?..).

[murarth]

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]

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]

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

[ticki]

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

[nrc]

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]

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

[sfackler]

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

[aturon]

@rust-lang/libs, thoughts on stabilization?

[alexcrichton]

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

@rfcbot fcp merge

[rfcbot]

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

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @brson
• @dtolnay
• @sfackler

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]

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

[cuviper]

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]

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]

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]

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]

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

[sagebind]

@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]

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

[cuviper]

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]

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]

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

[rfcbot]

The final comment period is now complete.