Subj : Re: pthreads and fork To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Mon Feb 21 2005 11:28 pm Marcin 'Qrczak' Kowalczyk writes: > That's why I'm still investigating a different semantics where the > thread doing the fork would suspend all threads in their safes points > first, and after fork cancel them from that points. I think waiting for > them to have signals unblocked has the right semantics most of the time. I implemented this. Actually I removed the previous semantics (cancel other threads in the child) and gave three choices: - ForkProcess - other threads are stopped at a point where signals are unblocked; the process is forked; in the child process threads are canceled, and in the parent they are resumed - ForkProcessCloneThreads - all threads continue running in both processes - ForkProcessKillThreads - other threads are killed immediately with no cleanup (used before ExecProgram) ForkProcess and ForkProcessCloneThreads run handlers registered with AtForkProcess. There is a handler installed by default which flushes StdOut/StdErr. Get{Addr,Name}Info which use a worker pthread install a handler which causes fork to be delayed until the worker finishes. The last choice corresponds to the interaction of POSIX fork with pthreads. It doesn't run the fork handlers however, because they are generally not needed if other threads don't exist in the child process and fork is soon followed by exec. If a program wants to do something interesting in the child before or instead of exec, ForkProcess should have the indended and safe semantics in most cases, at the cost of waiting for safe points and a possible deadlock if some threads wait indefinitely with signals blocked (or refuse to properly respond to a suspending signal). I mean Kogut signals, not Unix signals. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .