Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Perl Signals

by 7cardcha (Novice)
on Nov 14, 2011 at 00:46 UTC ( #937845=perlquestion: print w/replies, xml ) Need Help??
7cardcha has asked for the wisdom of the Perl Monks concerning the following question:

This code is supposed to print You can't kill me! whenever it is sent the INT signal
$SIG{"INT"} = "interrupt"; while(1) { } sub interrupt { print "You can't kill me!"; $SIG{"INT"} = "interrupt"; }
Instead it just does nothing. Please help.

Replies are listed 'Best First'.
Re: Perl Signals
by Anonymous Monk on Nov 14, 2011 at 01:39 UTC
      Thanks that worked perfectly. I should have remembered that from my c++ experience.
Re: Perl Signals
by Marshall (Abbot) on Nov 14, 2011 at 03:54 UTC
    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"; }
    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).
      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...

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


      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
        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!

        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.

Re: Perl Signals
by Albannach (Prior) on Nov 14, 2011 at 01:18 UTC
    You're making a piece of dumb text a handler. You need to reference the subroutine - try $SIG{'INT'} = \&interrupt;

    See also %SIG

    Ok, my bad, it seems you should be able to do what you tried (I've just never done it that way). Perhaps someone else can shed light on this.

    I'd like to be able to assign to an luser

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://937845]
Approved by BrowserUk
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2018-05-24 03:00 GMT
Find Nodes?
    Voting Booth?