On 3/31/06, Kripa Sundar <[EMAIL PROTECTED]> wrote: > Dear Ben, > > Thanks for the detailed reply to my query. > > If my questions below can be answered by online docs, please feel free > to point me to them. I read through the following docs before my > previous email. But I am still mostly in the dark: > > * "man -s 2" for fork(), wait(), waitpid() and kill() > * "perldoc -f" for fork(), wait(), waitpid() and kill() > * "perldoc perlipc"
Those are the right online docs. The perldocs for IPC::Open2 and IPC::Open3 are also good. Looking at examples helps a lot. The Cookbook is a good source. You can find an example at http://www.perlmonks.org/?node_id=28870. You can look at Parallel::ForkManager. etc. Unfortunately this tends to be a topic where you either get it or don't. And even when you get it, figureing out bugs is frustrating. > > 1 until -1 == wait(); > > > > You'll need something more complex if you want to track the children's > > exit statuses (very useful for debugging). > > That idiom is good to know. But I *do* need to track exit statuses > (stati?). Please see my pseudo-code below. So much for the simple answer... > > If you [use POSIX] you can > > > > $kid = waitpid(-1, WNOHANG); > > > > to poll to see if a kid needs to be reaped. [...] > > I've seen this verb "reap" in this context, but don't know what it > means. When and how do I "reap" a kid? How is "reaping" different > from kill()ing it? Terminology time. When a process is doing stuff, we say that it is alive. When it finishes everything it needs to do, it dies. After it dies it becomes a zombie process, meaning that the process is dead but not gone. In particular it needs to tell its parent what its exit status was. The process finally goes away when it delivers that message, and so we call asking for that exit status, "reaping". So reaping your child just means, "Finding out its exit status so that it can finally finish." Which happens when you call wait or waitpid. When I say, "poll to see if a kid needs to be reaped" I mean, "Check whether any child process has an exit status to tell me." > > Rather than worry about whether you are a child/parent for the rest of > > your code, I usually put an exit() here. [...] > > Sorry, I don't follow at all. When you are fork()ing my usual idiom is this: if (my $child_pid = fork()) { # Do parent stuff. } else { # Do child stuff. exit(); } # Do more parent stuff. That exit() guarantees that the child process can't accidentally execute code that it is not supposed to execute. > > Explicitly managing children and forking tends to be a lot of work. > > Unless you really need the complexity, I find that it tends to be > > easier to take the "poor man's" approach and do system calls and open > > up pipes. > > I'd much rather do system calls, if I can figure out how to wait for > the children to finish up. The code sample that I provided at http://www.perlmonks.org/?node_id=28870 might be good enough for you then. > All I really want is: > > system("something $_ &") for 1..5; > &wait_for_all_children; # "1 until -1 == wait;" might suffice. > &compute_summary_of_children_activities; > > But that won't really work, will it? system("something $_ &") will > launch "something" as a background job, and then come back in a flash > to tell me that I don't have any child. So &wait_for_all_children > won't have anything at all to wait for. Depending on what you mean by "work", that will work. That is, the code will run, jobs will be launched, children will be reaped, etc. But you'll have no way to tie the the children you reap to the jobs you ran. Which makes it hard to summarize what the children did. Cheers, Ben _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
