On Fri, Aug 8, 2008 at 9:43 AM, Yoann Vandoorselaere <[EMAIL PROTECTED]> 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. James.
