exit: explain our expectations for the exit handlers registered in a Rust program
This documents the position of @Amanieu and others in https://github.com/rust-lang/rust/issues/126600: a library with an atexit handler that destroys state that other threads could still be working on is buggy. We do not consider it acceptable for a library to say "you must call the following cleanup function before exiting from main or calling exit". I don't know if this is established @rust-lang/libs-api consensus so I presume this will have to go through FCP.
Given that Rust supports concurrency, I don't think there is any way to write a sound Rust wrapper around a library that has such a required cleanup function: even if we made exit unsafe, and the Rust wrapper used the scope-with-callback approach to ensure it can run cleanup code before returning from the wrapper (like thread::scope), one could still call this wrapper in a second thread and then return from main while the wrapper runs. Making this sound would require std to provide a way to "block" returning from main, so that while the wrapper runs returning from main waits until the wrapper is done... that just doesn't seem feasible.
The exit docs do not seem like the best place to document this, but I also couldn't think of a better one.
r? @joboet
rustbot has assigned @joboet. 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
We discussed this in today's @rust-lang/libs-api meeting. We felt that since this is documenting current reality, rather than adding a new guarantee, this doesn't need an FCP, just a lack of objections.
Based on the consensus from the meeting:
@bors r+
:pushpin: Commit 21dd88f963f8047fa6a3d0492fc7dcf86f5e5f4d has been approved by joshtriplett
It is now in the queue for this repository.
Also, separately, we may want an additional mention (in a separate doc PR) that on some targets simultaneous exits (if any of the exits are not from Rust) may cause UB.