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: Michael Kerrisk <mtk dot manpages at gmail dot com>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, Ian Pilcher <arequipeno at gmail dot com>, libc-help <libc-help at sourceware dot org>
- Date: Tue, 22 Dec 2015 12:31:22 -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>
On 12/22/2015 09:20 AM, Michael Kerrisk wrote:
> On Sat, Nov 14, 2015 at 5:25 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> 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.
>
> So, would it be acceptable to document in a man page that glibc
> supports malloc() and friends in the child of a fokr() in a
> multithreaded program?
I think we need to drive this as if it were a concurrency safety issue
and add a new "F-safe" or "Fork-safe" annotation in the glibc manual,
and then migrate those to the man pages after upstream has consensus on
exactly which functions are supported. Similarly "VF-safe" for vfork-safe
functions which we guarantee won't mess the parent's state.
I think that this will be less contentious than I think given how much work
we go to in order to make malloc fork-safe.
The list might be small enough that instead of cluttering the existing
safety tables we might simply include a section on "Fork Safety" to talk
about the problems, and then say, "The following is the list of functions
which are safe to call after fork:
- All async-signal-safe functions
- malloc, free, calloc, realloc ..."
What do you think?
In summary
- Get it into glibc manual after upstream agreement.
- Put it into similar page on man pages.
Cheers,
Carlos.