Front page | perl.perl5.porters |
Postings from January 2021
On Tue, Jan 12, 2021 at 8:32 PM Eric Wong <p5p@yhbt.net> wrote:
>
> Hi all, I noticed "local %SIG = (%SIG, PIPE => sub { ... })"
> wasn't restoring the old PIPE handler as I expected when I left
> that scope, but "local $SIG{PIPE} = sub { ... }" restores the
> old handler fine.
>
> I've relied on a similar thing "local %ENV = (%ENV, k => $v)"
> for ages, so is this anomaly for %SIG documented/expected?
>
> Example here:
> ----------8<---------
> use strict;
> use warnings;
> use Data::Dumper;
> $Data::Dumper::Deparse = 1;
>
> # this works as expected
> print 'outside before ', Dumper($SIG{PIPE});
> {
> local $SIG{PIPE} = sub { print "SIGPIPE\n" };
> print 'inside #1', Dumper($SIG{PIPE});
> }
> print 'outside middle expect and is undef', Dumper($SIG{PIPE});
>
> # this does not work as expected
> {
> local %SIG = (%SIG, PIPE => sub { print "SIGPIPE\n" });
> print 'inside #2 is sub', Dumper($SIG{PIPE});
> }
> print 'outside after expect undef, is sub?: ', Dumper($SIG{PIPE});
> kill 'PIPE', $$;
> select undef, undef, undef, 0.1; # wait for SIGPIPE to hit
> # "SIGPIPE\n" printed, why?
> ----------8<---------
> Thanks for any answer you can provide.
>
> Perl 5.32.0 on FreeBSD 11.x, but happens on 5.28.1 on Debian 10, too
Yeah, this is a bug. I think it has been reported before. %SIG magic
is a mess in general.
I think I know how to fix it though. The problem is that restoring
%SIG affects the Perl-level handlers (the SV in the hash) but not the
C-level signal disposition (sigaction).
Leon
Thread Previous
|
Thread Next