Run TLS destructors at process exit on all platforms

[surban]

This calls TLS destructors for the thread that initiates a process exit. This is done by registering a process-wide
exit callback.

Previously UNIX platforms other than Linux and Apple did not destruct TLS variables on the thread that initiated the process exit (either by returning from main or calling std::process::exit).

This also adds a test to verify this behavior.

@joboet Can we run CI tests for all available platforms for this?

r? joboet

[bors]

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

[joboet]

Sorry for the delay, I've been quite busy recently.

At a first glance, the changes look mostly good. There is a problem with the TLS destructor registration however: the TLS key can be used as soon as it is initialized, so it is possible that another thread completes before the destructor is registered. Always registering the destructor is not an option either, since that might lead to cycles in the destructor list. Windows uses INIT_ONCE synchronization to resolve this issue, but replicating that might prove difficult on platforms without a native Once-like interface (Once itself cannot be used in the TLS code since it needs TLS itself). I think this is best solved by keeping a thread-local destructor list similar to the one used on platforms with native TLS, but using the keys (or perhaps references to the LazyKeys) instead of pointers to values. Or perhaps you can think of another way?

[surban]

There is a problem with the TLS destructor registration however: the TLS key can be used as soon as it is initialized, so it is possible that another thread completes before the destructor is registered.

You are right.

I think this is best solved by keeping a thread-local destructor list similar to the one used on platforms with native TLS, but using the keys (or perhaps references to the LazyKeys) instead of pointers to values.

I implemented it using references to LazyKeys.

[surban]

I now have the problem that I need to register the LazyKey with the thread local list of destructors for every thread that uses it. Thus I need to call the register_dtor function once per thread that calls LazyKey::force.

Do you have an idea how I could achieve that without registering a second TLS key per LazyKey that keeps track whether it has been added to the destructors list? An option might be to store a sentinel value (for example 1 or 2) as the TLS value to indicate that the LazyKey been registered. However, I am unsure if this is acceptable practice. What do you think?

[surban]

I now have the problem that I need to register the LazyKey with the thread local list of destructors for every thread that uses it. Thus I need to call the register_dtor function once per thread that calls LazyKey::force.

I solved this by modifying os::Storage::get so that it checks if the value is being initialized for a particular thread. If so, it calls a function to add the TLS key to the thread-local destructor list. I hope this approach is okay.

This should be ready for review now.

[joboet]

I have some concerns about the implementation, but before that, I think T-libs should have a look at this to ensure that they are okay with the behaviour change: atexit doesn't just get run when main exits, but also when exit is called, which might be a bit unexpected.

@rustbot label +I-libs-nominated

[surban]

atexit doesn't just get run when main exits, but also when exit is called, which might be a bit unexpected.

Note that this is the same behavior as on currently stable Rust on Linux.

struct Foo;

impl Drop for Foo {
    fn drop(&mut self) {
        println!("wut");
    }
}

thread_local!(static FOO: Foo = Foo);

fn main() {
    FOO.with(|_| {});
    unsafe { libc::exit(0) };
}

The program above will print wut on rustc 1.84.0 (9fc6b4312 2025-01-07) on x86_64-unknown-linux-gnu with glibc 2.35.

[m-ou-se]

We briefly discussed this in the libs meeting. We'd like to understand the motivation better. Is this just for consistency? Or are there concrete bugs that are solved by this PR?

[surban]

There are several reasons for this:

• Consistency:
  Currently, TLS destruction on process exit is highly inconsistent—not only across different platforms but even between different glibc versions on Linux. See this comment. This inconsistency complicates testing and may introduce subtle bugs due to unexpected platform differences.

• Memory Leak Checking:
  Some tools report unfreed TLS memory as possibly lost (see issue #135608). While this is not a problem for the process itself since it is exiting anyway, it adds noise when debugging memory leaks—especially in scenarios involving unsafe code or linked C libraries. Avoiding such noise would improve the effectiveness of memory leak detection tools.

• Cross-Platform Exit Handlers:
  If TLS destructors were reliably executed on process exit, user code could use them as exit notifications, effectively enabling atexit-style callbacks without requiring unsafe or platform-specific code. This would benefit crates like tempfile, allowing them to perform cleanup even when local destructors are not executed (e.g., when std::process::exit is called).

Alternative: Never Run TLS Destructors

An alternative approach would be to never run TLS destructors on process exit. While this is not my preferred solution due to the reasons mentioned above, it would at least provide consistency and be easy to implement. This approach would also align with the behavior of static items.

[surban]

@rustbot ready

[the8472]

We discussed this again during today's libs meeting. Opinions were mixed, leaning towards close. The following issues were raised during the discussion:

• using TLS destructors as an exit handler is misguided because they would only run for the thread calling exit, other threads wouldn't get the desired cleanup behavior. So they should use atexit instead.
• consistency may become a burden, e.g. on platforms where atexit does not work reliably or causes other issues

Leak checking wasn't discussed, but from previous issues I have the impression that only limited effort is spent on making leak-checkers happy. Genuine leaks need to be fixed, false positives (quasi-static things) are better handled through exceptions in the leak checker.

@rfcbot fcp close

[rfcbot]

Team member @the8472 has proposed to close this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @cuviper
• @joshtriplett
• @m-ou-se
• @the8472
• @thomcc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.

[rfcbot]

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

[RalfJung]

Could you file an issue for this in the Miri repo? If std starts using this, we should consider supporting it.

[RalfJung]

This could use a few more comments, explaining what enable_thread / enable_process are doing. The names sound like they enable a thread/process but that's not quite right I think.

[RalfJung]

Are they guaranteed to not run? Or are they just not guaranteed to run? Does the implementation deal gracefully with implementations that run them anyway?

[RalfJung]

Oh never mind, I saw this in the FCP list but the list didn't say that this is "FCP close".

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.