Permute ThreadId values

[joboet]

As discussed on Zulip, users should never rely on the value of ThreadId, so apply a simple permutation when generating ids to make it appear random.

permute was ported from https://www.gkbrk.com/wiki/avalanche-diagram/ by @Pointerbender. It is not and does not need to be cryptographically secure.

[rustbot]

r? @Mark-Simulacrum

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[joshtriplett]

I really don't think we should do this.

I personally continue to think we should expose the underlying OS thread ID value. But if we're not going to do that, and we're making up our own values, is there some fundamental reason we should do this?

[joboet]

I personally continue to think we should expose the underlying OS thread ID value.

That would be a breaking change, since ThreadIds are guaranteed not to be reused, but e.g. pthread_t does not have that guarantee.

But if we're not going to do that, and we're making up our own values, is there some fundamental reason we should do this?

If I understood the Zulip discussion correctly, it was proposed to do this to stop users from thinking that the id indicated the creating order of threads.

[the8472]

I on the other hand believe that this doesn't go far enough and the permutation should be seeded with a random value, similar to hashmap iteration order.

But if we're not going to do that, and we're making up our own values, is there some fundamental reason we should do this?

The documentation says

The returned value is entirely opaque – only equality testing is stable. Note that it is not guaranteed which values new threads will return, and this may change across Rust versions.

Using a randomized permutation ensures that nobody relies on the value by accident. E.g. storing things by threadid in a btreemap and then relying on iteration order, writing tests against specific values or things like that.

[joshtriplett]

I don't think we should be treating users as adversaries like this.

[kennytm]

-1.

This is totally overkill to introduce a permutation function just to obfuscate the implementation detail that the thread IDs are distributed sequentially. I don't support anything more complicated than XOR-ing with some magic number.

[joboet]

To be honest, the more I think about it, the less I like this. Relying on the exact value of an id is a bug, and permuting them won't help users fix it more easily. Bugs because of randomness are just as hard to debug as bugs relying on operation ordering.

I'm keeping this PR up, in case T-libs decides to do this. Feel free to close it otherwise.

[m-ou-se]

Looking at all the comments above, it looks like there is not much enthusiasm for this change.

Feel free to close it

Doing that.