Front page | perl.perl5.porters |
Postings from December 2011
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 :-)
Leon
Thread Previous
|
Thread Next