The following issue has been SUBMITTED. 
====================================================================== 
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-22 16:38 UTC
====================================================================== 
Summary:                    Status of the thread-safety of exit is confusing
Description: 
exit is not listed as a thread-unsafe function. It hence seems reasonable
to assume that one can call exit concurrently from multiple threads.
However, this leads to a SEGFAULT in glibc
(https://sourceware.org/bugzilla/show_bug.cgi?id=31997), and the argument
of the glibc developers is that their implementation is permitted because
the standard says

"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."

This is taken directly from the C standard. However, this wording has been
in the C standard for a long time, even before there were threads, so it
was likely meant to rule out calls to exit from within the atexit
handlers.

The problem with the glibc interpretation of this wording is that it
becomes nearly impossible to call "exit" in a concurrent program, since
there is no way to to be sure that there is no other thread (managed by
some other library) that may call "exit" at the same time. (This is a
particular problem for Rust where being sure that things are safe is a key
premise of the language, see
https://github.com/rust-lang/rust/issues/126600.)



Desired Action: 
I hope POSIX could clarify that concurrent calls to "exit" are allowed
(atexit handlers may run concurrently, which can cause problems, but the
concurrent exit calls by themselves cannot be the source of UB).

====================================================================== 

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         
======================================================================


  • [1003.1(2024... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to