This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Concurrency semantics of fork


Hi Carlos,

On 12/22/2015 06:31 PM, Carlos O'Donell wrote:
> 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

Agreed.

> 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.

This seems a little heavyweight.

> 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?

I like the latter idea more. I suspect that the list of additional
functions (beyond async-signal-safe) would be quite small. So, having
some text like the above (in man-pages, that might go into pthreads(7),
for example) would I think be sufficient.

> In summary
> - Get it into glibc manual after upstream agreement.
> - Put it into similar page on man pages.

Okay.

I'm still not quite clear at this point: does glibc officially
guarantee malloc() and friends as "MT-fork-safe"?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]