Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Signals in Strawberry Perl: Name or number?

by Marshall (Prior)
on Sep 12, 2009 at 23:19 UTC ( #794948=note: print w/ replies, xml ) Need Help??


in reply to Signals in Strawberry Perl: Name or number?

A "signal" is a way for your program to process "asynchronous" events. Meaning that you register a subroutine to be called when that event occurs. When you do this, you don't have to explictly keep checking that a particular event occured, the OS will call the sub when that event occurs.

kill ALRM, $$ doesn't make sense to me!

The below code shows a simple example of a handler for SIGALRM.

#!/usr/bin/perl -w use strict; #$|=1; #see note below... $SIG{'ALRM'} = 'timeout'; alarm(1); while (1){sleep(1);} sub timeout { print "stdout: Alarming!\n"; print STDERR "stderr: Alarming!\n"; exit(0); }; __END__ prints: Note: stderr msg comes first because "autoflush" for stdout wasn't turned on (stdout normally doesn't get "flushed" until program end). $|=1; turns autoflush on. stderr: Alarming! stdout: Alarming!
Kill $some_number makes no sense if $some_number is not a PID. kill ALRM doesn't have a PID. ALRM on my system is "numeric 14", but that is just shorthand for what the string ALRM means.


Comment on Re: Signals in Strawberry Perl: Name or number?
Download Code
Re^2: Signals in Strawberry Perl: Name or number?
by Crackers2 (Vicar) on Sep 13, 2009 at 02:06 UTC
    kill ALRM, $$ doesn't make sense to me!

    It means "send an ALRM signal to the process with PID $$ (which mean the current process). While it may not make much sense in production code, it's certainly useful for testing.

    You may want to reread the docs for kill; unlike the shell version, the perl version requires you to have the signal as first parameter, followed by the PIDs you want to send the signal to.

      When I test code with ALRM signal, I fiddle with the alarm($num) parameter and often use sleep() to cause the alarm to "trigger" during testing. There are problems with signal handling...in general, there is no way to "safely" continue executing a process after an ALRM signal because many OS functions are not re-entrant or even re-startable by any means.

      Update: I strike this last sentence because it upset some folks. No offense was intended. I have no interest in obfuscated, obscure code although I do see that some folks have fun with this as an "art form".

      The original question was, why doesn't this code work?

      sub verse4 { my $boy; $SIG{ALRM} = sub { say "slip n slide" }; ride( $boy ), kill (ALRM, $$) for (1 .. 3); sleep 1; map { $_++ } ($ice_cream, $cake); } sub ride { say "Whee!" };

        There's no difference between receiving an alarm that was sent via alarm or via kill. What makes you think that the latter can trigger signals when the former can't?

        What's obfuscated about sending a signal with kill, whose very purpose is to send signals?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://794948]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (11)
As of 2014-07-30 11:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (230 votes), past polls