Subject: Re: [Boston.pm] Puzzling (to me) interaction between IO::Handle and
wait
uri> i know this is just an example script but i have some general
uri> comments anyway as well as a possible explanation for your issue.
uri>
uri> you can use lexical handles with open and it will autogenerate
uri> one for you. or if you must get one on your own, use
uri> Symbol::gensym. no need to make a sub to get one.
I haven't used Symbol::gensym before. I'll give it a look.
SR> my $pid = open($fh, "-|");
uri> you should also check for !defined $pid to see if the fork failed.
SR> exec("echo kid");
uri> just 'print "kid"; exit' would do the same.
Those are valid criticisms. The code I sent suffers from
small-examplitis, where the desire to produce a minimal example leads
one to do generally unhealthy things (like taking short cuts with
error checking). The Real World Version checks fork() for undef, does
a through examination of $?, and even spends a fair amount of time
examining the kids output (which is a bunch of analyic code run on
remote machines).
Just setting the record straight :)
uri> my guess is that the info associated with $fh that is used by
uri> waitpid is lost there. fileno gets a raw file number which is
uri> then reopened as a perl handle. so it has no association with the
uri> forked handle $fh.
Good point. I hadn't thought of that.
SR> DONE: PID=-1, status=-1 output=kid
uri> a -1 return from waitpid means there is no kid with that
uri> pid. possibly the kids were not done or were reaped some other
uri> way (odd if that).
That's what I thought as well (something else causing the child
processes to be reaped). I agree, it is odd. It's also odd that, in
spite of the waitpid() == $? == -1, the parent succeeded in reading
the kid's output ("output=kid").
I'll stick with the perl $fh's from open.
Steve
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
