On Oct 27, 2008, at 12:52 AM, Michael Ash wrote:
On Mon, Oct 27, 2008 at 12:07 AM, Michael Nickerson
<[EMAIL PROTECTED]> wrote:
You can always set things up to ignore child processes:
signal( SIGCHLD, SIG_IGN );
It's bad to rely on this sort of global state, though. What if some
other bit of code relies on having a handler for this signal? (Of
course it is relying on this sort of global state too in that case,
but it takes two to screw things up....)
Libraries and frameworks shouldn't be setting or relying on signals.
It is, as you say, a global state. So really, if you haven't
specifically set it in your app, you should be fine and if you have
you should already know about it.
That way, if the children aren't specifically reaped they don't
stay around
as zombies. Do note that the wait functions *do* still work if you
set that
up, so this isn't going to mess anything up elsewhere that is
reaping a
child.
How does that work, exactly? The whole purpose of the zombie is to
store the end state of the dead process so that wait() can pick it up.
If wait() still works, then what stores that end state if not a zombie
process? More to the point, if wait() still works, that implies that
*something*, *somewhere* is storing that end state. And if you never
call wait() but you continue to create children, that storage will
grow without limit, and this is bad. So it seems to me that either no,
wait() doesn't really work in this scenario, or in fact you still get
zombies or something like them. Am I missing something?
Sorry, my fault for replying late at night. The wait functions will
still block for the duration of the child process, but you do lose the
state information about it. So if you're relying on state information
I suppose you would consider that broken, but if all you're using wait
for is to wait until the child process has terminated, then it still
works as intended.
--------------------------------------
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
