[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87va4zc11z.fsf@oldenburg.str.redhat.com>
Date: Wed, 14 Nov 2018 13:10:16 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Adam Borowski <kilobyte@...band.pl>
Cc: Willy Tarreau <w@....eu>,
"Michael Kerrisk \(man-pages\)" <mtk.manpages@...il.com>,
Daniel Colascione <dancol@...gle.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Joel Fernandes <joelaf@...gle.com>,
Linux API <linux-api@...r.kernel.org>,
Vlastimil Babka <vbabka@...e.cz>,
Carlos O'Donell <carlos@...hat.com>,
"libc-alpha\@sourceware.org" <libc-alpha@...rceware.org>
Subject: Re: Official Linux system wrapper library?
* Adam Borowski:
> On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
>> A lot of multi-threaded applications assume that most high-level
>> functionality remains usable even after fork in a multi-threaded
>> process.
>
> How would this be even possible? Currently fork kills all threads
> (save for the caller).
glibc's fork acquires several locks around fork. Other mallocs install
fork handlers, too.
> Glibc's manpage also warns:
>
> # After a fork() in a multithreaded program, the child can safely call only
> # async-signal-safe functions (see signal-safety(7)) until such time as it
> # calls execve(2).
>
> Which makes sense as its malloc uses a mutex, and you can't take a breath
> without a library call using malloc somewhere (or in C++, the language
> itself).
Right, but applications require a working malloc after fork,
unfortunately. opendir is often used to enumerate file descriptors
which need closing, for example.
Thanks,
Florian
Powered by blists - more mailing lists