in reply to Re^3: Killing Forks
in thread Killing Forks

Hmm, thought it was working fine... But, the exit here seems to be necessary... I took it out and let it run and after getting back from getting my coffee I found that I had 1900+ processes running. Oops. Putting the exit back in before the call to the sub seems to stopped that from happening.
else { local $SIG {ALRM} = sub { print "$node KILLED $$\n"; exit(1)}; alarm 20; eval { ## child does... exit !&GetSvrStatus($node); }; }

Replies are listed 'Best First'.
Re^5: Killing Forks
by jbert (Priest) on Aug 14, 2007 at 16:15 UTC
    Ah, yes, sorry if I wasn't clear.

    I meant you could replace the kill, with an exit, not that you could skip the existing call to exit. You've done this nicely.

    The problem with the code which spawned many processes is that each child continued on to run the parent code, going on to wait for children and possibly start their own.

    You pretty much always want a good solid, unconditional 'exit' in the child codepath after a fork, otherwise you have a case where the child can start running the parent code. (Sometimes this is what you want, of course).

Re^5: Killing Forks
by cdarke (Prior) on Aug 14, 2007 at 16:18 UTC
    If you miss out the exit, the CHILD will go around the for loop again, and create more children like damn wabbits.
    The rule for inherited signal handlers is: DEFAULT and IGNORE will be inherited, anything else will not.