Re: [PATCH] conditions variables module

[Yoann Vandoorselaere]

Le vendredi 08 août 2008 à 17:10 +0100, James Youngman a écrit :
> 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).

It's up to the application writer to support fork handler for each place
in the library where a lock will have to be reinitialized. 

On the other end, an application writer does not have control on lock
from other dependencies, and have to rely on theses library to export
the necessary fork handler (which is a risky bet).

Then there's also the problem of platforms that does not even provide
the pthread_atfork() function.

I guess we can all agree that this situation is suboptimal..


>    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.

The supposed way to use pthread_atfork is that the prepare fork handler
will be called prior to the process forking so that the application can
lock the program to solidify it in a known state.

Then, once the process is forked, parent and child fork handler are
invoked, where the application is supposed to release all the lock, to
resume operation.

-- 
Yoann Vandoorselaere <address@hidden>