Perl Signals

7cardcha has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Perl Signals by Anonymous Monk on Nov 14, 2011 at 01:39 UTC
You're suffering from buffering. You'll see output if you use `print "You can't kill me!\n"` Tutorials: Input and Output: Suffering from Buffering?	[reply] [d/l]
Re^2: Perl Signals by 7cardcha (Novice) on Nov 14, 2011 at 02:40 UTC
Thanks that worked perfectly. I should have remembered that from my c++ experience.	[reply]
Re: Perl Signals by Marshall (Canon) 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"; }` [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).	[reply] [d/l]
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]
Re^3: Perl Signals by Marshall (Canon) on Nov 14, 2011 at 22:23 UTC
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]
Re^4: Perl Signals by afoken (Chancellor) on Nov 17, 2011 at 16:51 UTC
Re^3: Perl Signals by ikegami (Patriarch) on Nov 14, 2011 at 19:30 UTC
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]
Re: Perl Signals by Albannach (Monsignor) 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	[reply] [d/l]