Concurrency semantics of fork

[Carlos O'Donell]

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.