From: Florian Weimer <fweimer@redhat.com> To: Adam Borowski <kilobyte@angband.pl> Cc: Willy Tarreau <w@1wt.eu>, "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>, Daniel Colascione <dancol@google.com>, linux-kernel <linux-kernel@vger.kernel.org>, Joel Fernandes <joelaf@google.com>, Linux API <linux-api@vger.kernel.org>, Vlastimil Babka <vbabka@suse.cz>, Carlos O'Donell <carlos@redhat.com>, "libc-alpha\@sourceware.org" <libc-alpha@sourceware.org> Subject: Re: Official Linux system wrapper library? Date: Wed, 14 Nov 2018 13:10:16 +0100 [thread overview] Message-ID: <87va4zc11z.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: <20181114120348.or5id3hzrmltkyvb@angband.pl> (Adam Borowski's message of "Wed, 14 Nov 2018 13:03:48 +0100") * 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
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com> To: Adam Borowski <kilobyte@angband.pl> Cc: Willy Tarreau <w@1wt.eu>, "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>, Daniel Colascione <dancol@google.com>, linux-kernel <linux-kernel@vger.kernel.org>, Joel Fernandes <joelaf@google.com>, Linux API <linux-api@vger.kernel.org>, Vlastimil Babka <vbabka@suse.cz>, Carlos O'Donell <carlos@redhat.com>, "libc-alpha@sourceware.org" <libc-alpha@sourceware.org> Subject: Re: Official Linux system wrapper library? Date: Wed, 14 Nov 2018 13:10:16 +0100 [thread overview] Message-ID: <87va4zc11z.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: <20181114120348.or5id3hzrmltkyvb@angband.pl> (Adam Borowski's message of "Wed, 14 Nov 2018 13:03:48 +0100") * 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
next prev parent reply other threads:[~2018-11-14 12:10 UTC|newest] Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-10 18:52 Official Linux system wrapper library? Daniel Colascione 2018-11-10 19:01 ` Willy Tarreau 2018-11-10 19:06 ` Daniel Colascione 2018-11-10 19:33 ` Willy Tarreau 2018-11-10 19:20 ` Greg KH 2018-11-10 19:58 ` Vlastimil Babka 2018-11-12 2:03 ` Carlos O'Donell 2018-11-12 2:24 ` Carlos O'Donell 2018-11-12 2:36 ` Greg KH 2018-11-12 16:08 ` Jonathan Corbet 2018-11-12 20:03 ` Greg KH 2018-12-09 4:38 ` Randy Dunlap 2018-12-10 16:27 ` Jonathan Corbet 2018-12-10 17:39 ` Carlos O'Donell 2018-12-10 23:32 ` Randy Dunlap 2018-11-12 5:46 ` Andy Lutomirski 2018-11-11 6:55 ` Michael Kerrisk (man-pages) 2018-11-11 8:17 ` Willy Tarreau 2018-11-11 8:25 ` Daniel Colascione 2018-11-11 10:40 ` Florian Weimer 2018-11-11 10:40 ` Florian Weimer 2018-11-11 10:30 ` Florian Weimer 2018-11-11 10:30 ` Florian Weimer 2018-11-11 11:02 ` Willy Tarreau 2018-11-11 12:07 ` Florian Weimer 2018-11-11 12:07 ` Florian Weimer 2018-11-11 10:53 ` Michael Kerrisk (man-pages) 2018-11-11 11:02 ` Florian Weimer 2018-11-11 11:02 ` Florian Weimer 2018-11-12 16:43 ` Joseph Myers 2018-11-13 15:15 ` Carlos O'Donell 2018-11-11 11:11 ` Willy Tarreau 2018-11-11 11:46 ` Florian Weimer 2018-11-11 11:46 ` Florian Weimer 2018-11-11 12:09 ` Willy Tarreau 2018-11-12 12:25 ` Florian Weimer 2018-11-12 12:25 ` Florian Weimer 2018-11-12 17:36 ` Joseph Myers 2018-11-12 17:53 ` Greg KH 2018-11-12 18:09 ` Joseph Myers 2018-11-12 18:14 ` Randy Dunlap 2018-11-12 16:59 ` Joseph Myers 2018-11-14 12:03 ` Adam Borowski 2018-11-14 12:10 ` Florian Weimer [this message] 2018-11-14 12:10 ` Florian Weimer 2018-11-16 21:24 ` Alan Cox 2018-11-11 11:09 ` Florian Weimer 2018-11-11 11:09 ` Florian Weimer 2018-11-11 14:22 ` Daniel Colascione 2018-11-12 1:44 ` Paul Eggert 2018-11-12 8:11 ` Florian Weimer 2018-11-12 8:11 ` Florian Weimer 2018-11-12 13:19 ` Daniel Colascione 2018-11-12 17:24 ` Zack Weinberg 2018-11-12 18:28 ` Daniel Colascione 2018-11-12 19:11 ` Florian Weimer 2018-11-12 19:11 ` Florian Weimer 2018-11-12 19:26 ` Daniel Colascione 2018-11-12 22:51 ` Joseph Myers 2018-11-12 23:10 ` Daniel Colascione 2018-11-12 23:26 ` Joseph Myers 2018-11-12 22:34 ` Joseph Myers 2018-11-13 19:39 ` Dave Martin 2018-11-13 20:58 ` Andy Lutomirski 2018-11-14 10:54 ` Dave Martin 2018-11-14 11:40 ` Florian Weimer 2018-11-14 11:40 ` Florian Weimer 2018-11-15 10:33 ` Dave Martin 2018-11-14 11:58 ` Szabolcs Nagy 2018-11-14 14:46 ` Andy Lutomirski 2018-11-14 15:07 ` Florian Weimer 2018-11-14 15:07 ` Florian Weimer 2018-11-14 17:40 ` Joseph Myers 2018-11-14 18:13 ` Paul Eggert 2018-11-14 14:58 ` Carlos O'Donell 2018-11-14 17:15 ` Arnd Bergmann 2018-11-14 18:30 ` Joseph Myers 2018-11-14 18:30 ` Joseph Myers 2018-11-14 15:40 ` Daniel Colascione 2018-11-14 18:15 ` Joseph Myers 2018-11-14 18:35 ` Daniel Colascione 2018-11-14 18:47 ` Joseph Myers 2018-11-15 5:30 ` Theodore Y. Ts'o 2018-11-15 16:29 ` Joseph Myers 2018-11-15 17:08 ` Theodore Y. Ts'o 2018-11-15 17:14 ` Joseph Myers 2018-11-15 21:00 ` Carlos O'Donell 2018-11-15 20:34 ` Carlos O'Donell 2018-11-23 13:34 ` Florian Weimer 2018-11-23 13:34 ` Florian Weimer 2018-11-23 14:11 ` David Newall 2018-11-23 15:23 ` Szabolcs Nagy 2018-11-24 3:41 ` David Newall 2018-11-28 13:18 ` David Laight 2018-11-23 20:15 ` Daniel Colascione 2018-11-23 23:19 ` Dmitry V. Levin 2018-11-12 12:45 ` Szabolcs Nagy 2018-11-12 14:35 ` Theodore Y. Ts'o 2018-11-12 14:40 ` Daniel Colascione
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87va4zc11z.fsf@oldenburg.str.redhat.com \ --to=fweimer@redhat.com \ --cc=carlos@redhat.com \ --cc=dancol@google.com \ --cc=joelaf@google.com \ --cc=kilobyte@angband.pl \ --cc=libc-alpha@sourceware.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mtk.manpages@gmail.com \ --cc=vbabka@suse.cz \ --cc=w@1wt.eu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.