[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3da15edb-d7a4-4737-b145-78543e7b39ce@redhat.com>
Date: Fri, 26 Jul 2024 17:00:29 -0400
From: Carlos O'Donell <carlos@...hat.com>
To: musl@...ts.openwall.com,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
libc-coord@...ts.openwall.com, enh <enh@...gle.com>
Cc: libc-alpha@...rceware.org
Subject: Re: Re: [libc-coord] Making exit actually thread-safe
On 7/25/24 8:48 AM, Adhemerval Zanella Netto wrote:
>
>
> 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.
I agree, it's the most conservative thing. I just reviewed your patch on libc-alpha.
Thanks for working on that.
I'm *tempted* to try adding an abort() in the case of atexit() calling exit() and
running a Fedora mass-rebuild to see what triggers :}
--
Cheers,
Carlos.
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.
