From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: Official Linux system wrapper library? Date: Wed, 14 Nov 2018 13:10:16 +0100 Message-ID: <87va4zc11z.fsf@oldenburg.str.redhat.com> References: <20181111081725.GA30248@1wt.eu> <3664a508-ca74-4ff0-39a6-34543194a24e@gmail.com> <20181111111143.GB4189@1wt.eu> <87zhufvntw.fsf@oldenburg.str.redhat.com> <20181114120348.or5id3hzrmltkyvb@angband.pl> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <20181114120348.or5id3hzrmltkyvb@angband.pl> (Adam Borowski's message of "Wed, 14 Nov 2018 13:03:48 +0100") Sender: linux-kernel-owner@vger.kernel.org To: Adam Borowski Cc: Willy Tarreau , "Michael Kerrisk (man-pages)" , Daniel Colascione , linux-kernel , Joel Fernandes , Linux API , Vlastimil Babka , Carlos O'Donell , "libc-alpha@sourceware.org" List-Id: linux-api@vger.kernel.org * 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