std: lazily allocate the main thread handle

[joboet]

#123550 eliminated the allocation of the main thread handle, but at the cost of greatly increased complexity. This PR proposes another approach: Instead of creating the main thread handle itself, the runtime simply remembers the thread ID of the main thread. The main thread handle is then only allocated when it is used, using the same lazy-initialization mechanism as for non-runtime use of thread::current, and the name method uses the thread ID to identify the main thread handle and return the correct name ("main") for it.

Thereby, we also allow accessing thread::current before main: as the runtime no longer tries to install its own handle, this will no longer trigger an abort. Rather, the name returned from name will only be "main" after the runtime initialization code has run, but I think that is acceptable.

This new approach also requires some changes to the signal handling code, as calling thread::current would now allocate when called on the main thread, which is not acceptable. I fixed this by adding a new function (with_current_name) that performs all the naming logic without allocation or without initializing the thread ID (which could allocate on some platforms).

Reverts #123550, CC @GnomedDev

r? @ChrisDenton

rustbot has assigned @ChrisDenton.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

I've also moved the Thread code into its own module, the size of thread/mod.rs is just getting out of hand.

std::thread::thread here we come?

EDIT: I was right!

I'd be happy with this approach but it would be nice to have some consensus on it to (hopefully) avoid further churn. I won't insist on it though.

Why is this change is needed?

Because this is also used when 64-bit atomics are unavailable.

Is there any more specific cfg that can be used? #[allow(unused)], while sometimes necessary, makes me nervous because it could silently become actual dead code in the future.

This change seems worse. Having an invariant that can be violated in safe code is not great.

I also wondered if it made sense to have a new-type that held both invariants (UTF-8 & c-string \0 ending) ?

Utf8CStr is a fairly common type in the ecosystem, it would make sense for us to start tinkering with providing it.

Also could you separate the file move into a different commit? It's easier to diff that way.

Blocked on the efficiency fix in #132730, without that, we'd be creating a new Thread for every blocking RwLock call on macOS.

@rustbot label +S-blocked

☔ The latest upstream changes (presumably #133219) made this pull request unmergeable. Please resolve the merge conflicts.

I've undone the Thread move (that's probably worth another PR) and fixed some other things related to signal handling (thread::current now allocates on the main thread, so we mustn't call it in the signal handler).

@rustbot ready

☔ The latest upstream changes (presumably #135279) made this pull request unmergeable. Please resolve the merge conflicts.

☔ The latest upstream changes (presumably #135357) made this pull request unmergeable. Please resolve the merge conflicts.

@bors r=ChrisDenton

📌 Commit 2c28cc4 has been approved by ChrisDenton

It is now in the queue for this repository.