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-26 12:26 UTC ====================================================================== Summary: Status of the thread-safety of exit is confusing ======================================================================
---------------------------------------------------------------------- (0006846) carlos (reporter) - 2024-07-26 12:26 https://austingroupbugs.net/view.php?id=1845#c6846 ---------------------------------------------------------------------- The issue around the concurrency of atexit() handlers is interesting, and not something I'd previously considered. There is a good argument to be made that exit() latency impacts process restart latency and that has an impact on rolling security updates, or functional safety. However, in all of these cases you could have designed the system to be robust enough to allow _Exit(), but that isn't always possible with complex compositions of software. So at a first blush I agree that developers expect today that one thread of execution carries exit() from start to completion with atexit() handlers running as required in the reverse order of registration. Historically glibc developers held the position that when you called exit() you could do everything without locks because the standard said you couldn't call exit() from another thread of execution. That position has evolved considerably over the years, particularly because of the evolution and focus on threading in both language standards and the development community. Today we are all working to make operations self-synchronizing and MT-Safe, but sometimes it's really hard. The exit() case isn't that hard, and I agree that we need to make this MT-Safe under concurrent calls to exit(), anything else is a disservice to developers composing complex applications. My personal position is that exit() from atexit() handlers should fail early and catastrophically, likely with an abort(), since this case is easy to detect (very low detection cost) and the abnormal termination would help the developer debug the scenario. Detecting other forms of UB are much harder. The wrinkle here is that if existing applications rely on such behaviour we may be unable to do this UB detection in this way, and may have to revert it from an implementation perspective, but we could try. The AS-safe case only allows _Exit() or _exit() so that's fine, a terminating signal handler in the current or other threads of execution can just terminate the process skipping the atexit or other handlers. Overall I agree with Rich's position and proposed language. 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 ======================================================================
