develooper Front page | perl.perl5.porters | Postings from June 2013

[perl #22735] Losing signals using sigprocmask

Leon Timmermans via RT
June 9, 2013 22:18
[perl #22735] Losing signals using sigprocmask
Message ID:
On Thu Jun 19 01:33:15 2003, wrote:
> #!/usr/bin/perl -w
> use POSIX;
> use Data::Dumper;
> $SIG{HUP} =  sub { print "in HUP handler\n";};
> my $blockset = POSIX::SigSet->new(SIGHUP);
> my $set = POSIX::SigSet->new(SIGHUP);
> sigprocmask(SIG_BLOCK, $blockset, $set)
>     or $::ENV->error("Can't block SIGHUP : $!");
> #open FH, "cat|" or die "cat|$!\n";
> print "TEST\n";
> <>; # Comment
> #<FH>;
> print "TEST2\n";
> #close FH;
> sigprocmask(SIG_UNBLOCK, $blockset, $set)
>     or $::ENV->error("Can't unblock SIGHUP : $!");
> print "TEST3\n";
> The program as listed above runs as expected: i.e.
> When I sent a SIGHUP to the process while it is waiting for
> input, the line "in HUP handler" appears between TEST2 and TEST3.
> However if I uncomment the commented lines and comment the line
> marked with '#Comment' and I sent a SIGHUP to the perl process
> (i.e. not the cat) while the process is waiting for the <FH>
>  I never see the "in HUP handler" line.
> So, apparently the signal gets lost.

To quote POSIX:

"Some historical implementations of pclose() either block or ignore the
signals SIGINT, SIGQUIT, and SIGHUP while waiting for the child process
to terminate. Since this behavior is not described for the pclose()
function in IEEE Std 1003.1-2001, such implementations are not conforming."

Perl is such an implementation. Setting the signal disposition to ignore
may throw away any pending signals even when they're blocked. This logic
was implemented in perl 3.0 back in 1989.

I pushed a fix that removed this logic entirely to a smoke-me branch.


via perlbug:  queue: perl5 status: open Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About