Run TLS destructors for wasm32-wasip1-threads

[surban]

The target wasm32-wasip1-threads has support for pthreads and allows registration of TLS destructors.

For spawned threads, this registers Rust TLS destructors by creating a pthreads key with an attached destructor function.
For the main thread, this registers an atexit handler to run the TLS destructors.

try-job: test-various

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jhpratt (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

As suggested I have switched to using the UNIX thread_local implementation for WASI.

For now I have added the missing libc declarations locally.
What is the way forward here? Shall I open a PR with the missing functions against the libc crate and then update the libc version of std?

Note that the new implementation shows the behavior described in #28129.

However, this is consistent with the behavior of other UNIX platforms. I tested on FreeBSD and there TLS destructors are also not run for the main thread.

I have created follow-up PR #133819 that deals with calling TLS destructors when the main thread exits on UNIX platforms other than Linux.

r? @joboet

You seem to have more knowledge of how this works, so feel free to take it over. I don't see anything wrong with the PR, though.

As suggested I have switched to using the UNIX thread_local implementation for WASI.

Great, thanks!

For now I have added the missing libc declarations locally.
What is the way forward here? Shall I open a PR with the missing functions against the libc crate and then update the libc version of std?

I'm totally OK with temporarily adding these here. A PR on libc would be appreciated though!

Note that the new implementation shows the behavior described in #28129.

However, this is consistent with the behavior of other UNIX platforms. I tested on FreeBSD and there TLS destructors are also not run for the main thread.

Considering that this is documented as a caveat, I think this is fine for now, especially since this PR is already a big improvement over the status quo.

I have created follow-up PR #133819 that deals with calling TLS destructors when the main thread exits on UNIX platforms other than Linux.

Cool, I'll have a look soon!

@bors r+

📌 Commit 4fe15b0 has been approved by joboet

It is now in the queue for this repository.

I believe this failed in rollup:

  error[E0432]: unresolved import `crate::sys::thread_local::destructors`
    --> library/std/src/sys/thread_local/guard/key.rs:10:9
     |
  10 |     use crate::sys::thread_local::destructors;
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `destructors` in `sys::thread_local`
     |
  note: found an item that was configured out
    --> library/std/src/sys/thread_local/mod.rs:54:16
     |
  54 | pub(crate) mod destructors {
     |                ^^^^^^^^^^^
  note: the item is gated here
    --> library/std/src/sys/thread_local/mod.rs:53:1
     |
  53 | #[cfg(all(target_thread_local, not(all(target_family = "wasm", not(target_feature = "atomics")))))]
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Included the test-various try job in case anyone wants to run it, which would exercise this test.

@bors r-

This was caused by not distinguishing between wasm32-wasip1 and wasm32-wasip1-threads.

Should be fixed now.

@rustbot review

@bors r+

📌 Commit 4f16640 has been approved by joboet

It is now in the queue for this repository.

When users compile to wasm32-wasip1-threads, they don't necessarily enable target_feature = "atomics", but the rust-std of wasm32-wasip1-threads always enables atomics, which causes some issues: #137510.

Move this to #137510 (comment)