> So you had a bug in your code. So what? No bug - read this:
http://www.unix.org/version2/whatsnew/threadspaper.ps : Registration of fork handlers (pthread_atfork( )). The fork handlers are routines that are to be executed in association with calls to the fork( ) function. There are three classes of fork handlers: prepare, parent, and child. Prepare fork handlers are executed prior to fork() processing, in the context of the calling thread. Parent fork handlers are executed upon completion of fork() processing in the parent, again in the context of the calling thread. Child fork handlers are executed upon completion of fork() processing in the child, in the context of the single thread initially existing in the child process. Fork handlers are envisioned as a mechanism for dealing with the problem of orphaned mutexes that can occur when a multi-threaded process calls fork(). The problem arises when threads other than the calling thread own mutexes at the time of the call to fork( ). Since the non-calling threads are not replicated in the child process, the child process is created with mutexes locked by non-existent threads. These mutexes can therefore never be unlocked. Fork handlers are intended to resolve the problem of orphaned mutexes in the following way. Prepare fork handlers can be written to lock all mutexes. In this way, orphaned mutexes are avoided, and the resources protected by the mutexes are not left in inconsistent states. This is due to the fact that the calling thread itself, which is replicated in the child process, has locked all mutexes. Thus, both the parent and child processes have all mutexes locked upon completion of fork() processing, at which time the parent and child fork handlers execute. The parent and child fork handlers unlock mutexes locked by the prepare fork handler. Fork handlers are especially useful in enabling independently-developed libraries and application programs to protect themselves from one another. A multi-threaded library can protect itself from application programs that issue fork( ) operations, possibly without even knowing that the library is multi-threaded, by providing fork handlers. Similarly, an application program can protect itself from fork( ) operations issued by library functions > 3) You cannot link to the pthreads library and still use fork, and David, you absolutely cannot link with pthreads and still use fork()!!!! It doesn't work except in a few very simplistic scenarios. -paul
