Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: Re: controling the num of fork sessions

by mikfire (Deacon)
on Nov 27, 2000 at 19:51 UTC ( #43497=note: print w/replies, xml ) Need Help??

in reply to Re: controling the num of fork sessions
in thread controling the num of fork sessions

A nice solution, but I would suggest ( as I almost always do to this kind of question ) a few improvements.

Why are you going through all this pain with REAPERs and counters? Handle the child's death yourself in the main loop of the code. This obviates some complexity and also gets around perl's rarely ( honestly, I have never seen this interupt problem in about 6 years of perl programming, but that is merely anecdotal ) seen interupt problems.

What I would suggest ( and have used several times ) is a loop like this:

while( $again ) { #-- # Initial loop to spawn children #-- if ( $ref < $max ) { if ( $cpid = fork ) { $kids{ $cpid } = 1; } else { #do interesting process here exit; } $ref++; } else { do { select undef, undef, undef, 0.5; $dpid = waitpid( -1, 1 ); } until $dpid; last if ( $dpid == -1 ); # No children left delete $kids{$dpid}; if ( $cpid = fork ) { $kids{ $cpid } = 1; } else { # Same interesting process exit; } } $total++; }
There is some complexity here - I was using this to seriously abuse some cycles :) The if() portion merely checks to see if all the children have been spawned. If they haven't, spawn another off and log the creation into a hash.

If all the children have been spawned, poll the system every 1/2 second until one dies. I make sure I have a real pid, dropping out of the loop if not, and remove that entry from the tracking hash. This hash can be used to log when a child has died and what it was doing. Spawn another child off and loop again.

Because I am handling the deaths myself and not waiting for quasi-mystical signals, even if 100 children die at the same time, each child will remain in the process table until I have processed it. I can then be certain that I will spawn 100 more children off, no matter how or when they die.

Oh. This loop was actually run as a child process - my loop exitted when the signal handler set $again. You can replace this with a variety of exit conditions - timeouts, all the children have been reaped, etc.


Replies are listed 'Best First'.
Re: Re: Re: controling the num of fork sessions
by Fastolfe (Vicar) on Nov 27, 2000 at 21:13 UTC
    I was using the signal approach so as to free up the parent process for other things. The use of waitpid in a loop as I was doing should also catch all 100 children if they die simultaneously (under the announcement of a single signal). The only problem might be with unreliable signals. It's just a preference thing.. I would rather not devote a process solely to the task of keeping track of children. Signals (or I guess a more complex event loop) let me do that while allowing me to work on other things at the same time.

    I really don't see it as a pain keeping track of stuff like that. You're using a hash of PID's to keep track of your kids, I was going under the assumption that a count was adequate. TMTOWTDI.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://43497]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2017-08-16 20:18 GMT
Find Nodes?
    Voting Booth?
    Who is your favorite scientist and why?

    Results (274 votes). Check out past polls.