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 (man-pages)" <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 15:06: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>
On 12/22/2015 02:56 PM, Michael Kerrisk (man-pages) wrote:
>> 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.
Sounds good. I'll try to do that.
>> 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"?
Unofficially yes. We have tons of code in malloc to handle this.
However, I'm just an steward/developer, and not the community,
so I can't make this statement without some consensus discussion
first. Which won't happen until the January (after the holidays).
Cheers,
Carlos.