[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZoqxGtz9Bn4F=LsvKXWraGnyUmu3eKG4U7Z6THnJg=otCg@mail.gmail.com>
Date: Wed, 24 Jul 2024 17:21:00 -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
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...
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.
