Concurrency semantics of fork

[Carlos O'Donell]

On Mon, Dec 28, 2015 at 2:36 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Carlos O'Donell:
>
>> On 12/22/2015 02:56 PM, Michael Kerrisk (man-pages) wrote:
>>> I'm still not quite clear at this point: does glibc officially
>>> guarantee malloc() and friends as "MT-fork-safe"?
>>
>> Unofficially yes. We have tons of code in malloc to handle this.
>
> But only if fork is not called from a signal handler (in case this
> isn't obvious).

That's a very good point to make.

We could technically cleanup after a fork from a signal handler, but
it would likely require a lot of atomic operations in the various APIs
which you are expecting to use after the fork. The goal being to have
the forked child inherit a global state that can be cleaned up.

So while possible, it's not easy and restricts the designs quite a bit.

Cheers,
Carlos.