This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Concurrency semantics of fork
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-help at sourceware dot org
- Date: Thu, 12 Nov 2015 20:41:34 -0200
- 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>
On 12-11-2015 16:16, Ian Pilcher wrote:
> 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.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html
> http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
>
Yes, since POSIX state the new process will be single thread based on the thread
that actually called fork you do not have any guarantee about the lock
state. Even if fork is a full barrier regarding the shared memory operations
it won't matter for the child since all the concurrent tasks won't be cloned.