On Thu Dec 08 09:26:48 2011, rcaputo2 wrote: > Using $SIG{CHLD} to reap signals causes system() to return -1 on > success. The $SIG{CHLD} reaper snatches the PID from system()'s hand > before it's time to leave. > > print system('echo "without reaper: "'), "\n"; > sub REAPER { > while ((my $pid = waitpid(-1 , WNOHANG)) != -1) { > print "reaped: $pid\n"; > } > }; > $SIG{CHLD} = \&REAPER; > print system('echo "with reaper: "'), "\n"; > > Output shows that it's wise to fear the REAPER(). > > % ./perl ../../support/sigchld-system.pl > without reaper: > 0 > with reaper: > reaped: 50696 > -1 > > There seems to be a workaround. I've tried to implement it, but I > don't have the core chops to get it working yet. > > PP_system() uses Perl_wait4pid() to wait for a particular PID. > > It could be possible to block SIGCHLD in PP_system() before > PerlProc_fork(). > > PERL_USES_PL_PIDSTATUS must be in effect. Perl_wait4pid() must enter > exit statuses for "uninteresting" PIDs into PL_pidstatus. > Perl_wait4pid() seems to do this after the "hard_way" goto target. > > PP_system() can unblock SIGCHLD and dispatch pending PL_pidstatus > entries before returning. The presence of S_pidgone() implies that > something alreayd exists to dispatch SIGCHLD out of PL_pidstatus. > > A minimal patch might get away with enabling PERL_USES_PL_PIDSTATUS on > troublesome platforms (BSD?), and masking and restoring SIGCHLD in > PP_system. > Patch attached :-) LeonThread Previous | Thread Next