On Feb 16, 5:40 am, [email protected] (Shawn H Corey) wrote:
> C.DeRykus wrote:
> > On Feb 15, 12:35 pm, [email protected] (Shawn H Corey) wrote:
> >> Normally a program continues but if it is waiting or sleeping, it
> >> continues after the command. You have to redo the command until it
> >> terminates correctly. Example: waiting for a child process:
>
> >> my $child_pid = 0;
> >> WAIT_BLOCK: {
> >> $child_pid = wait();
> >> redo WAIT_BLOCK if $child_pid == 0 || $child_pid < -1;
>
> >> }
>
> > No, you don't need 'redo' on a blocking wait. I see why you
> > might conclude that reading the waitpid doc but I believe the
> > that doc is mis-leading in not clarifying that only a non-blocking
> > wait, ie, WNOHANG, will potentially return a 0.
>
> From the man page on wait: Otherwise they block until either a child
> changes state or a signal handler interrupts the call.
>
> The system call wait(2) does return when interrupted by a signal. What
> is not clear in the Perl documentation is whether it puts a wrapper
> around the wait(2) to filter out when it returns from a signal.
>
> So, be paranoid: put the wait in a block and redo it until its response
> is not -1 or positive.
>
No, you don't need to do that. If the child is interrupted by an
uncaught
signal, the child terminates and its status can be inspected, eg.
use POSIX ":sys_wait_h";
my $reaped_pid = wait();
if ( WIFSIGNALED($?) ) { # uncaught signal
print "child terminated by a ", WTERMSIG($?), "\n";
}
( See perlipc. Also, 5.10 introduced something called
${^CHILD_ERROR_NATIVE} mentioned in the wait
doc whose significance I don't understand completely.)
> Note that this is also true of sleep; it may return early if interrupted
> by a signal.
>
?
sleep is implemented with a SIGALRM and, if there're dueling SIGALRM
signals, you can get an early return, but that's a different issue.
--
Charles DeRykus
--
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
http://learn.perl.org/
