[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240724190948.GH10433@brightrain.aerifal.cx>
Date: Wed, 24 Jul 2024 15:09:48 -0400
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Cc: musl@...ts.openwall.com, libc-alpha@...rceware.org
Subject: Making exit actually thread-safe
Inspired by Rust issue 126600, there seems to be renewed interest in
the (non-) thread-safety of exit, namely the C (and copied in POSIX
text) stipulation that calling exit "more than once" results in
undefined behavior.
This language predates threads and thus was certainly written with
recursive calls (via atexit handlers) in mind as the way one might
come to call exit "more than once".
My view is that making calls to exit from multiple threads (one or
more additional threads while the first caller is still acting on
exit) undefined is a mistake and is harmful. There is a clear unique
reasonable behavior for this situation: any remaining callers block
until the first call to exit has finished, at which point they no
longer exist. Leaving exit via longjmp, exceptions, etc. is undefined,
so there are no concerns about what happens in such a situation. The
additional calls to exit all behave as expected: the process
terminates.
Currently there is a glibc tracker item, #31997, and an Austin Group
(POSIX) tracker item, #1845, open for this topic, as well as the
original Rust tracker thread. I have participated in all of these, and
would like to move this forward towards consensus on whether any new
thread-safety requirement should be adopted, and if so, what the
specific semantics should be.
Links:
https://github.com/rust-lang/rust/issues/126600
https://sourceware.org/bugzilla/show_bug.cgi?id=31997
https://austingroupbugs.net/view.php?id=1845
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
