note
papidave
<small>
<b>Disclaimer</b>
<p>
The following note applies to unix-like system calls only. My mojo does not apply to windows.
</small>
<p>
As [tye] apparently explained to you, most SysV-style (and by exension, linux) system calls are interruptible. The wait(2) and waitpid(2) calls are examples.
<p>
Since your database connection to MySQL needs to use sockets to communicate with the database, you may receive signals (SIGPOLL is common with asynchronous I/O, for example). Likewise, if you have a second process in the background, it can send a SIGCLD when it exits. And timers send SIGALRM.
<p>
The fun part of this is that Unix only stacks one of each signal for calls to the handler -- so your signal handler might only get called <i>once</i> even when <i>two</i> processes die. This doesn't just apply to <tt>$SIG{FOO}</tt> handlers, it also applies to the implicit handler in <tt>wait()</tt> calls. I haven't (yet) walked the Perl source to satisfy my curiosity, but I expect that since it uses <tt>waitpid()</tt>, it's trapping that case reasonably well.
<p>
Some test cases I ran using <tt>system()</tt> and <tt>alarm()</tt> shows that the $! value sometimes (but not always) gets set to "interrupted system call" when this occurs. It depends on where you are in the system call when the signal arrives, I think. In any event, my general rule is to trust the value of <b><tt>( $? >> 8 )</tt></b>, which gives the return status of the child process. YMMV, especially if you were to create more than one child process -- i don't know which one would end up in $?.
<p>
I have definitely seen the case where the signal arrives and the child process continues running to completion long after the return code is "returned." In C, I avoid the whole thing by calling popen() and reading until end-of-file. I don't know if you can apply that technique to wget in perl using <tt>open my $fh, '-|', $cmd</tt> or not.
641620
641620