develooper Front page | perl.perl5.porters | Postings from July 2012

[perl #28961] unsafe signals

Thread Next
Leon Timmermans via RT
July 3, 2012 06:17
[perl #28961] unsafe signals
Message ID:
On Mon Apr 19 08:51:15 2004, wrote:
> This example will hang (it should deliver SIGUSR1 and die "OK").
> It will work as expected if some delay will be added in chield
> process before kill(), for example:
> unless ($chield_pid) { sleep 1; kill 10, $parent_pid; exit };
> Also it will work as expected without adding this delay if
> safe signals will be used:
> $sigaction->safe(1);
> ---cut---
> use POSIX;
> $sigaction = POSIX::SigAction->new(sub {die "OK\n"});
> $sigaction->safe(0);
> sigaction(10, $sigaction);
> my $parent_pid = $$;
> die "can't fork\n" unless defined(my $chield_pid = fork());
> unless ($chield_pid) { kill 10, $parent_pid; exit };
> sleep 2;
> print "Exit !!!\n";
> ---cut---
> BTW, where I can found list of async-signal safe perl functions?
> For example, is sysread() safe?

Calling the handler isn't async-signal safe in the first place (nothing
that may allocate memory is), so does it matter if any builtin you call
in it is safe? There's a limited number of circumstances in which it is
safe, and I don't think core has any way of triggering any of them.

More than that, dieing is more than just async-signal unsafe, it's so
verboten CERT has an explicit advisory against the C construct (longjmp)
that's used to implement it: [SIG32-C], on top of the one that advices
against async-signal unsafe.

I can reproduce this issue on a CentOS 5 machine (using 5.8.8 and 5.16),
but not on my own Ubuntu machine (5.14 and 5.16). It would seems the
platform has become more tolerant of this undefined condition, but it
has every right to hang (or format your hard-drive). I'd suggest closing
this as "wontfix".



via perlbug:  queue: perl5 status: open

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About