[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240725001917.GJ10433@brightrain.aerifal.cx>
Date: Wed, 24 Jul 2024 20:19:18 -0400
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Cc: musl@...ts.openwall.com, libc-alpha@...rceware.org
Subject: Re: Making exit actually thread-safe
On Wed, Jul 24, 2024 at 05:21:00PM -0400, enh wrote:
> you didn't want to go with the recursive mutex variant mentioned? i'm
> convinced by this change for Android too, but was leaning towards the
> recursive mutex myself...
The change I'm advocating for first is a minimal one, just making
calls from other threads well-defined by blocking until the process
terminates. This is a trivial change that any implementation can adopt
without breaking anything else, and doesn't have any potential
far-reaching consequences.
While some implementations may want to allow (or feel they already
allow, often by accident) recursive calls to exit, imposing a
requirement to do this without a deep dive into where that might lead
seems like a bad idea to me. Even if it is desirable, it's something
that could be considered separately without having the thread-safety
issue blocked on it.
By leaving the recursive case undefined as it was before, any
implementations that want to do that or keep doing that are free to do
so.
Rich
> On Wed, Jul 24, 2024 at 4:53 PM Konstantin Belousov <kostikbel@...il.com> wrote:
> >
> > On Wed, Jul 24, 2024 at 03:09:48PM -0400, Rich Felker wrote:
> > > 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
> >
> > I do think that the wording in the austin group bug is reasonable, and
> > intend to do that for FreeBSD, https://reviews.freebsd.org/D46108
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.
