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


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?

Cheers,

Michael


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