Subj : Re: pthreads and fork To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Sat Feb 19 2005 10:58 pm Alexander Terekhov writes: >> on fork. And since I'm designing the language to make asynchronous >> cancelation quite safe, ... > > Asynchronous cancelation is safe within async-cancel-safe regions. This is a tautology. The point is how large async-cancel-safe regions can be in order to be still safe. My language automatically blocks signals in some constructs (e.g. locking a mutex) and makes them synchronous in others (e.g. waiting for a resource in the "using" construct), such that programs rarely need to block them explicitly, and thus functions are often async-signal-safe even without explicit management of blocking. Unix signals and thread cancellation are both mapped to my signals. > You can't do "interesting" things in async-cancel-safe regions but > hypothetical forkall() can be told to treat all your async-cancel- > safe regions as fork points (akin to pthread_cancel() treating all > async-cancel-safe regions as sorta "tall" cancel points). Hmm, this suggests an interesting alternative semantics of ForkProcess: before canceling all threads, wait until they all reach a point where signals are enabled, and suspend each thread in that point until the fork is done. Then in the parent process threads are resumed, while in the child they are canceled. This increases the number of computations which are safe for forking without their explicit collaboration, at the cost of delaying some others which would be safe to fork without suspending, and risking a deadlock if some thread is waiting forever with signals blocked. Waiting with signals blocked is not nice but is allowed. What is worse, it might wait for a thread which we just suspended. It will not happen with waiting for a mutex, because a thread which has locked a mutex has signals blocked by default and a thread which tries to lock a mutex has them unblocked by default (the exact opposite of the case which would cause trouble), but it might happen with waiting for something else. Fortunately it seems unlikely... Would this be a more useful semantics of ForkProcess than relying on explicit AtProcessFork handlers? It doesn't replace AtProcessFork completely: for example I currently flush StdOut/StdErr before forking, and this would still have to be done separately. > Again, all you need is safe forkall(). File a DR/ER. Lack of forkall() is not a defect but lack of functionality. Since I'm almost not using pthreads, I don't know whether it would help me. Depending on its semantics it might make Get{Addr,Name}Info safe for forking, or maybe not, I'm not sure... -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .