[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87eeo6ikhi.fsf@mid.deneb.enyo.de>
Date: Sun, 16 Aug 2020 19:11:37 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Restrictions on child context after multithreaded fork
* Rich Felker:
> On Sun, Aug 16, 2020 at 11:10:37AM +0200, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > On some inspection, glibc does not actually attempt to make the child
>> > environment unrestricted. The only things it does around fork are:
>>
>> I think pthread_once initializers that have partially executed are
>> also executed from the start in the child if initialization is
>> requested again.
>
> I don't follow how pthread_once is related. The vast majority of the
> things I found glibc doing no specific handling for are actual mutable
> state not just on-demand initialization.
If a fork happens during a pthread_once initialization, the subsystem
related to that becomes unavailable after fork. The pthread_once_t
reinitialization logic intends to avoid that. Like resetting locks
after fork in the new process, it is rather questionable.
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.
