A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1845 ====================================================================== Reported By: ralfjung Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1845 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Ralf Jung Organization: User Reference: Section: exit Page Number: unknown Line Number: unknown Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2024-07-22 16:38 UTC Last Modified: 2024-08-02 14:10 UTC ====================================================================== Summary: Status of the thread-safety of exit is confusing ======================================================================
---------------------------------------------------------------------- (0006854) carlos (reporter) - 2024-08-02 14:10 https://austingroupbugs.net/view.php?id=1845#c6854 ---------------------------------------------------------------------- In general a C library today may have to consider the following: * Coordination with a C++ runtime for the registration of C++ object destruction during library unloading or exit * Concurrent dlclose(), exit(), _exit(), _Exit(), abort(), quick_exit(), and pthread_exit() * Asynchronous signal safety of abort() * Implementation of atexit() and exit() * Implementation of at_quick_exit() and quick_exit() * Implementation of legacy on_exit() * Arrival of implementation dependent signals e.g. SIGCANCEL, SIGSETXID; or application controlled signals during library unloading or shutdown * Concurrent multi-threaded fork() with atfork() registration and deregistration via dlclose() I mention all of these for completeness as I hold them in mind while reviewing the proposed text. I am consciously limiting the scope of my review to process and thread exit. The suggested changes cover the cases for atexit(), exit(), at_quick_exit(), and quick_exit(). Wording for _exit() and _Exit() which may also be called concurrently are left untouched. As expected this means that it is well defined to call _exit() or _Exit() from any registered shutdown handlers. The proposed text looks good to me. The interesting remaining case is dlclose() for registered exit handlers, fork handlers or other language-specific handlers. I think the easiest answer is to say that dlclose(), exit() and quick_exit() are all multi-threaded safe (this is what the standard says today), and so the implementation must ensure that calling them in any order from any thread is allowed. With my developer hat on I'd expect some happens-before ordering between dlclose() and the other exit functions, either the dlclose() happens first or doesn't happen at all. The trivial implementation is that dlclose() takes the same recursive exit lock, which allows registered exit handlers to call dlclose() themselves (allowed) but any other thread would be blocked from calling exit() or quick_exit() until the dlclose() completes. This means that dlclose() has a shutdown-latency penalty, but allows plugin frameworks to operate concurrently to process exit without ordering issues around deregistration of exit handlers, fork handlers, and language-specific handlers. In summary, I don't think anything should be said about dlclose() and exit() or quick_exit(), letting the multi-threaded safety stand as the requirement for correctness. Issue History Date Modified Username Field Change ====================================================================== 2024-07-22 16:38 ralfjung New Issue 2024-07-22 16:38 ralfjung Name => Ralf Jung 2024-07-22 16:38 ralfjung Section => exit 2024-07-22 16:38 ralfjung Page Number => unknown 2024-07-22 16:38 ralfjung Line Number => unknown 2024-07-24 19:05 dalias Note Added: 0006842 2024-07-24 19:34 ralfjung Note Added: 0006843 2024-07-26 12:26 carlos Note Added: 0006846 2024-07-26 12:37 enh Note Added: 0006847 2024-07-26 12:39 wakely Note Added: 0006848 2024-07-26 20:50 carlos Note Added: 0006849 2024-07-26 22:28 dalias Note Added: 0006850 2024-07-29 16:12 carlos Note Added: 0006851 2024-07-31 15:27 dalias Note Added: 0006852 2024-08-01 16:31 geoffclare Note Added: 0006853 2024-08-01 16:32 geoffclare Note Edited: 0006853 2024-08-02 14:10 carlos Note Added: 0006854 ======================================================================
