[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c44ff3ea-df10-410f-8759-e27836163a7f@linaro.org>
Date: Thu, 25 Jul 2024 09:48:46 -0300
From: Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>
To: libc-coord@...ts.openwall.com, enh <enh@...gle.com>
Cc: musl@...ts.openwall.com, libc-alpha@...rceware.org
Subject: Re: [libc-coord] Making exit actually thread-safe
On 25/07/24 09:39, enh wrote:
> 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.)
I think it is reasonable to not add the constraint to allow recursive
exit, although making this implementation defined will most likely
pressure to eventually have the resolution on the most used behavior
(unless it is broken by design).
At least for glibc, my plan is to keep current support of allowing it
so mostly likely we will use a recursive mutex.
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.
