Re^4: 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);
                };
        }
[download]

Comment on Re^4: Killing Forks Download Code

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).	[reply] [d/l] [select]
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.	[reply]