Clear questions and runnable code get the best and fastest answer |
|
PerlMonks |
Re^2: using waitpid() with signalsby ristov (Initiate) |
on Jan 21, 2017 at 08:40 UTC ( [id://1180070]=note: print w/replies, xml ) | Need Help?? |
hi Ken,
the solution you have suggested looks like my last example, except that the presence of the child process is verified with kill(0, $pid), not waitpid($pid, WNOHANG). The use of kill() involves one caveat, though -- it merely checks that the process with the given PID exists, but that does not mean this process is a child. In order to illustrate this, suppose you are logged in as root and execute the following commandline:
On my Linux laptop, this commandline always prints out the message "Init is our child", although this is not true. This caveat can lead to the following race condition -- if the signal handler gets triggered after waitpid($pid, 0) has returned *and* the OS has had enough time to start a new process with the same PID, the new process can mistakenly get the TERM signal. I acknowledge that modern operating systems attempt not to reuse the same PID immediately, but I wouldn't like to rely on that assumption in the code, especially because it will be executing with root privileges and can thus kill any process in the system. In contrast, waitpid($pid, WNOHANG) returns 0 for running child processes only, and a new unrelated process with the same PID is not reported as a running child. That's why I was asking if it is OK to call waitpid() again from the signal handler, if the blocking waitpid() call was interrupted by the signal. regards, risto
In Section
Seekers of Perl Wisdom
|
|