nested alarm signals (fwd)

[The Chazman]

~sdpm~
> Is there some kind of Unix rule that you can't have nested alarm
> signals?

Yes, that's exactly the case.  The signal being handled is always
blocked while its signal handler is running.

> Even if there was such a rule for a single process, it
> seems odd to me that the child process for alarm_die.pl would be
> affected by the fact that it was run from within an alarm signal
> handler.

There are a large number of system calls that are unsafe to make while
inside a signal handler.  Any attempt to call these may result in
incorrect, undefined, or otherwise disastrous behavior.  I was looking
for a complete list, but failed to find one.  However, I'm certain that
among them are: fork, exec, read, and write.

That means no spawning other processes, and no file or terminal I/O
while in a signal handler.  Frankly, I'm amazed your example executed
as far as it did.  Keep your signal handlers short and simple.

> Sorry that this is more of a Unix question than Perl, but it is kind
> of Perl, isn't it?

Sorta.  Sometimes Perl makes it hard to see exactly what system calls
are happening when.  In most cases, that contributes to its appeal, but
now is definitely not one of those cases.


                         Carl N Miller
                         chaz at devastator.extern.ucsd.edu
~sdpm~

The posting address is: san-diego-pm-list at hfb.pm.org

List requests should be sent to: majordomo at hfb.pm.org

If you ever want to remove yourself from this mailing list,
you can send mail to <majordomo at happyfunball.pm.org> with the following
command in the body of your email message:

    unsubscribe san-diego-pm-list

If you ever need to get in contact with the owner of the list,
(if you have trouble unsubscribing, or have questions about the
list itself) send email to <owner-san-diego-pm-list at happyfunball.pm.org> .
This is the general rule for most mailing lists when you need
to contact a human.