[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZoqFe3OSc-HND3Bz4AFmCx9OtRZTNzrv0ZXQP92KnJbEgw@mail.gmail.com>
Date: Thu, 25 Jul 2024 08:39:27 -0400
From: enh <enh@...gle.com>
To: libc-coord@...ts.openwall.com
Cc: musl@...ts.openwall.com, libc-alpha@...rceware.org
Subject: Re: [libc-coord] Making exit actually thread-safe
On Wed, Jul 24, 2024 at 8:19 PM Rich Felker <dalias@...c.org> wrote:
>
> 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)
yeah, i think that was what made me lean toward the recursive mutex
--- the assumption that _that's_ the option least likely to break
anyone. (i actually thought that was the point of even mentioning it
in the proposal --- the assumption that someone somewhere has an
atexit() handler that calls exit(). normally at this point i'd say "if
i've learned one thing in a decade+ of dealing with Android's libc and
the third-party binary app ecosystem, it's that no matter how crazy a
thing, if you can imagine it, someone's relying on it already", but
since "exiting" isn't really a thing on Android -- you're either
backgrounded or kill -9'ed, and don't typically have any kind of
"quit" functionality yourself -- this is one place where it seems
relatively unlikely.)
> 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.
aye, but a program that calls exit() from an atexit() handler is
working for me right now on Android, glibc, and macOS. so there's a
user-visible behavior change here for any of those libcs that goes
with a non-recursive mutex. (i think the same is true for musl too,
but don't have a musl-based system to test on.)
> 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.
