Subj : Re: pthreads and fork To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Sat Feb 19 2005 05:25 pm Alexander Terekhov writes: >> Which one? > > 3. But you can of course roll your own leak-free fork() framework with > registry of resources to clean up and safe synchronous forking when all > threads meet each other at fork point(s) (must call them periodically). The threads are under my control, as are fork calls, and I can synchronize whatever I need. But in order to implement anything which calls fork while more than one thread is running, I must know what happens with resources associated with pthread_t in the child process. I know about pthread_atfork, but it doesn't help, it doesn't say what should be done. Either choice is OK for me, as long as I can detect which is the case. Experiments on Linux/NPTL show that pthread_join succeeds on these threads (the exit value of such thread is a null pointer). I want to know whether I can rely on that (i.e. whether pthread_join can be called in this case - I don't care abou the exit value), or it's just that implementation, or maybe even on Linux it doesn't have to work. And whether on implementations where pthread_join is not allowed, its resources will be reclaimed automatically, or I'm not supposed to use fork while threads are running at all (unless just before exec). If on a significant number of systems the behavior is defined, in either way, perhaps I can test at configure time which is the case, and make code which makes use of that possibility when possible. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .