http://www.perlmonks.org?node_id=937863


in reply to Perl Signals

there is no need for "$SIG{"INT"} = "interrupt";" within interrupt() subroutine. I would take that out. 

sub interrupt
{
   my $sig_name = shift;
   print "You can't kill me! $sig_name caught";
}

[download]
the signal name should be first arg when interrupt() is called. So you can set up one interrupt routine that handles multiple signals (don't strictly need one handler per signal).

Replies are listed 'Best First'.
Re^2: Perl Signals
by afoken (Chancellor) on Nov 14, 2011 at 10:10 UTC
    there is no need for "$SIG{"INT"} = "interrupt";" within interrupt() subroutine.

    Interesting, because perlipc documents it this way:

    or better still: 
    use POSIX ":sys_wait_h";
sub REAPER {
    my $child;
    # If a second child dies while in the signal handler caused by the
    # first death, we won't get another signal. So must loop here else
    # we will leave the unreaped child as a zombie. And the next time
    # two children die we get another zombie. And so on.
    while (($child = waitpid(-1, WNOHANG)) > 0) {
        $Kid_Status{$child} = $?;
    }
    $SIG{CHLD} = \&REAPER; # still loathe SysV
}
$SIG{CHLD} = \&REAPER;
# do something that forks...

    [download]

    So, has perl's behaviour changed (when?), is one of SIGINT, SIGCHLD special for perl, or is perlipc simply out-of-date?

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
      Starting with 4.3BSD and System V Release 3, signal handlers remain installed after a signal occurs. So, yes, the requirement to re-install a signal handler is some super ancient (many decades ago) stuff. No modern system and no POSIX compliant system will cause an installed signal handler to be affected. I would think that the Perl docs should be updated.

      Now, this while() loop in the reaper is definitely needed! Signals are not "queued" for delivery. When a signal occurs, always interpret that to mean "at least one and maybe more than one of this signal has occurred".

      Update: Wiki ATT releases SVR3, SVR4. SVR3 was GA'ed in 1986. I figure after 25 years, we don't have to worry much about R2 any more!

[reply]
        [...] the requirement to re-install a signal handler is some super ancient (many decades ago) stuff. [...] I would think that the Perl docs should be updated.

        So do I.

        this while() loop in the reaper is definitely needed

        I have no problem with the while loop in the reaper, it is properly explained in perlipc.

        On the other hand, so is the problem with old SysV behaviour:

        But that will be problematic for the more complicated handlers that need to reinstall themselves. Because Perl's signal mechanism is currently based on the signal(3) function from the C library, you may sometimes be so unfortunate as to run on systems where that function is "broken"; that is, it behaves in the old unreliable SysV way rather than the newer, more reasonable BSD and POSIX fashion. So you'll see defensive people writing signal handlers like this:

        I think the paragraph cited above and the two examples following it should be moved into a new section "Signal Handlers on Ancient Systems" ("pre-POSIX systems"?), and be replaced with text and examples that concentrate on handling SIGCHLD / wait / waitpid instead of working around ancient API problems.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]

      Nothing to do with Perl.

      Some system remove the handler once it has caught a signal. If you want your program to handle more than one instance of the signal on those platforms, you need to set the handler again in the handler.

      I don't know what those systems are. Not your everyday systems. I think it's "SysV" systems, whatever that means.

[reply]

In Section Seekers of Perl Wisdom