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 redhat dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>, Ian Pilcher <arequipeno at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Fri, 13 Nov 2015 23:25:08 -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>
On 11/13/2015 06:05 PM, Florian Weimer wrote:
> * 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.
Correct. POSIX is the minimum we offer in many places and we should srive
to solve real user problems and usage patterns. Particularly when we have
already an implicit or explicit agreement to do so.
c.