site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com To avoid getting SIGCHLD delivered, something along the lines of this should work: My previous mails were based on the faulty understanding that handling a SIGCHLD would reap the zombie process(es) that caused the signal to be posted. I believe this is incorrect. SIGCHLD is an indication that one should call wait()/waitpid()/... to reap the zombie(s). Eric PS: <http://www.faqs.org/faqs/unix-faq/faq/part3/section-13.html> PPS: I still claim that blocking SIGCHLD (and most signals but for things like SIGILL/SIGBUS/SIGSEGV) is the right way to go in multi-threaded applications. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Apologies for the spam to Kevin and the list. I need to clarify something. On Apr 6, 2006, at 20:45 , Eric Gouriou wrote: So, to address Kevin's original question, there shouldn't be any risk of seeing the PID of a direct child reused until wait()/waitpid()/... is explicitly called and returns the given PID. If that's the setup you have, you cal kill() the process group without fear. This email sent to site_archiver@lists.apple.com