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

I was composing this perl poem and I ran into a strange issue with the kill command. I've only used it once before (Perl 5.10.0 on Ubuntu) and it worked fine, but this time, every time I try to kill ALRM, $$, the program quits. I tried kill 14, $$, same issue. I had set a signal handler for SIGALRM:

kill() doesn't have the semantics of raise(), i.e. it doesn't send a signal to the identified process like it does on Unix platforms. Instead kill($sig, $pid) terminates the process identified by $pid, and makes it exit immediately with exit status $sig. As in Unix, if $sig is 0 and the specified process exists, it returns true without actually terminating it. (Win32)

kill(-9, $pid) will terminate the process specified by $pid and recursively all child processes owned by it. This is different from the Unix semantics, where the signal will be delivered to all processes in the same process group as the process specified by $pid. (Win32)

Signal handling may not behave as on Unix platforms (where it doesn't exactly "behave", either :). For instance, calling die() or exit() from signal handlers will cause an exception, since most implementations of signal() on Win32 are severely crippled. Thus, signals may work only for simple things like setting a flag variable in the handler. Using signals under this port should currently be considered unsupported.

Alexander

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

(The quotes around 'ALRM' required for strict).
I don't have Strawberry Perl, but I tried it on ActiveState Perl 5.10.1 and got the same result, i.e. no output. I tried it on 5.10.0 on Cygwin and 5.8.8 on CentOS(Linux) and it worked correctly, i.e.

On Windows and ActiveState perl, tracing shows that it does exit on the kill. I tried the same with an INT signal and that did not work either, however the symptoms were different. It did not execute the signal handler but it did not crash either.

The ActiveState documentation says that alarm is not supported and signals are not properly supported anyhow. It's a Windows thing, but neither implementation should just drop-out without so much as a 'sorry'. The code is perfectly legal, if a bit of an edge case.

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.

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".

On another note, though, I'm curious about that. Does die SIGALRM actually raise a SIGALRM to the calling process, similar to POSIX::raise? If so, is it a POSIX thing, or can I use die SIGSTOP and so forth without useing POSIX?

Went to join the gridlock to see it
Held an eclipse party
Watched a live feed
I cn"t see tge kwubosd to amswr thus
I tried to see it, but 8000 miles of rock got in the way
What eclipse?
Wanted to see it, but they wouldn't reschedule it
Read the book instead