This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Concurrency semantics of fork
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, Ian Pilcher <arequipeno at gmail dot com>, libc-help <libc-help at sourceware dot org>
- Date: Mon, 28 Dec 2015 20:57:28 -0500
- Subject: Re: Concurrency semantics of fork
- Authentication-results: sourceware.org; auth=none
- References: <56389D0F dot 5030305 at redhat dot com> <5640D977 dot 6090100 at linaro dot org> <56413D36 dot 7000409 at redhat dot com> <n22l2h$bg5$1 at ger dot gmane dot org> <87fv09pkjr dot fsf at mid dot deneb dot enyo dot de> <5646B7A4 dot 9000305 at redhat dot com> <CALxWeYrW5dBmebt7Dn+ttbNzKFUsOYS1OC+GEKwbCOJhtU7=MQ at mail dot gmail dot com> <567988EA dot 7020601 at redhat dot com> <5679AAFC dot 7040104 at gmail dot com> <5679AD44 dot 3030506 at redhat dot com> <87ziwupdph dot fsf at mid dot deneb dot enyo dot de>
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.