This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Concurrency semantics of fork
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Ian Pilcher <arequipeno at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Sat, 14 Nov 2015 00:05:28 +0100
- 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>
* Ian Pilcher:
> On 11/09/2015 06:41 PM, Carlos O'Donell wrote:
>> Assume a lockless malloc implementation and then fork. What guarantees does
>> the child have with regards to the state of the structures in such a malloc
>> implementation?
>
> POSIX explicitly says that you can't make any assumptions about the
> state of a multi-threaded application after calling fork. Thus you're
> only allowed to call async-safe functions between fork and one of the
> exec functions.
glibc supports malloc after fork in multi-threaded programs as an
extension, I assume. There is quite a bit of code to support this
functionality. I don't think we can remove it. We have to fix it
instead.