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-07-24 19:05 UTC ====================================================================== Summary: Status of the thread-safety of exit is confusing ======================================================================
---------------------------------------------------------------------- (0006842) dalias (reporter) - 2024-07-24 19:05 https://austingroupbugs.net/view.php?id=1845#c6842 ---------------------------------------------------------------------- atexit handlers should not be allowed to run concurrently. This is a major semantic change no existing code is written to be prepared for, and is not a reasonable behavior to program to. Fortunately such a behavior is not needed; it's just the current manifestation of the undefined behavior in some implementations, due to unlocking the atexit function list lock between calls in order to handle registration of new atexit handlers by atexit handlers. The reasonable behavior for second and later calls to exit while exit is already in progress is for them to block until the process terminates. This is easily achieved in an implementation by adding a lock at the top of the exit function. However, if the implementation intends to allow atexit handlers themselves to call exit (note: this is also undefined behavior), such a change would make these recursive calls deadlock. Implementations that wish to allow this, however, can do so just by using a recursive lock at the top of exit. Conversely, implementation that wish to disallow it without deadlocking can trap or issue a diagnostic when the recursive lock is taken successfully a second time. The fix I'd like to propose: Change the text from: "If a process calls the exit() function more than once, or calls the quick_exit() function in addition to the exit() function, the behavior is undefined." to "If a function registered by a call to atexit() calls exit(), directly or indirectly, the behavior is undefined." And in the prior paragraph detailing atexit functions, add: "All functions registered by atexit() shall execute in the first thread to call exit(). If any other thread of the process calls exit() before all registered functions have completed or before the process terminates, it shall block until the process terminates." 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 ======================================================================
