[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181114120348.or5id3hzrmltkyvb@angband.pl>
Date: Wed, 14 Nov 2018 13:03:48 +0100
From: Adam Borowski <kilobyte@...band.pl>
To: Florian Weimer <fweimer@...hat.com>
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@...rceware.org" <libc-alpha@...rceware.org>
Subject: Re: Official Linux system wrapper library?
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 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).
So any functionality remaining usable after fork is pretty strictly
limited...
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism
⠈⠳⣄⠀⠀⠀⠀ (funeral doom metal).
Powered by blists - more mailing lists