[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] conditions variables module

From: James Youngman
Subject: Re: [PATCH] conditions variables module
Date: Fri, 8 Aug 2008 17:10:22 +0100

On Fri, Aug 8, 2008 at 9:43 AM, Yoann Vandoorselaere
<address@hidden> wrote:
> Le vendredi 08 août 2008 à 00:37 +0200, Bruno Haible a écrit :

>> gl_thread_atfork ?! Sounds advanced and weird to implement as well.
> This one is especially important for library using threads: if an
> application fork, the library won't be able to recover without this
> function.

Neither can it recover with it, either.    In general, the prepare
handler can't actually put the process into a state in which it is
safe to duplicate its memory image.   The memory image includes lock
states in the application and in libraries, and the prepare handler
doesn't have any way to lock them all or unlock them all (in fact, it
can't even enumerate them).   In the child, the lock states will
appear to be the same but since only one thread will exist in the
child, the threads which would have then ordinarily went on to unlock
held locks, don't even exist.   The fork system call presents a number
of problems for thread-using processes, and pthread_atfork doesn't
really solve them.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]