Re: waitid() function replacement
Re: waitid() function replacement
- Subject: Re: waitid() function replacement
- From: Eric Gouriou <email@hidden>
- Date: Thu, 6 Apr 2006 21:40:23 -0700
Apologies for the spam to Kevin and the list. I need to clarify
something.
On Apr 6, 2006, at 20:45 , Eric Gouriou wrote:
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).
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.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden