Thanks Andrew for the explanation... but
I just read the signals section of Programming Perl 2nd edition (my
precious book with Larry Walls autograph, camel stamp and TMTOWTDI stamp)
which cautions against doing anything worthwhile after handling a signal,
since the underlying C routines are not re-entrant on most platforms. In
my case there is only one instance of the script required to run at any
time (ha ha, soon there will pop up an exception!) , so it is OK.
The book also states that you can not IGNORE or trap a A KILL or STOP
signal. Is it still the case with Perl 5.8 and Linux kernel 2.4x?
#+++++++++++++++++++++= Lastly ++++++++++++++++++++++++#
Ronald, Could we please set the Reply-To: to the mailing list address
please, pretty please?
#++++++++++++++++++++++++++++++++++++++++++++++++++++#
Thanks
Andrew Langmead <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/31/2004 04:59 PM
To: Ranga Nathan <[EMAIL PROTECTED]>
cc: Boston List <[EMAIL PROTECTED]>
Subject: Re: [Boston.pm] Completing processing before
SIGHUP
On May 31, 2004, at 3:33 PM, Ranga Nathan wrote:
> Andrew Langmead <[EMAIL PROTECTED]>
> You should probably get your hands on a copy of Advanced Programming in
> the UNIX Environment
> <http://www.aw-bc.com/catalog/academic/product/0,,0201563177,00%2ben-
> USS_01DBC.html> by W. Richard Stevens. It is one of the best
> references I have seen for how the OS intereracts with applications for
> matters like this.
[stuff deleted. I probably could have deleted the above too, but it is
a great book and I wanted the opportunity to recommend it again.]
> You can set your $SIG{HUP} handler in a manner like: "my $hangup = 0;
> $SIG{HUP} = sub { $hangup=1 };" and then check if the value of $hangup
> changes.
>
> This implies that normal execution continues have the HUP is handled
> and
> it is the application responsibility to recognize the change to the
> variable. Am I reading it right? If so this is the exact behaviour I
> want.
> so long as the execution resumes after the signal handling, it is up to
> the application to do whatever it can to reach a stable state and then
> terminate.
Yes. Nearly every signal can be blocked, caught, or left to its default
action. The default action for most signals is to terminate the
process, which is the behavior you are used to seeing. If the signal
is caught, the normal execution of your program is put aside, the
signal handler run, and then you program resumes as normal. A signal
handler is sort of like a subroutine that your program ran but wasn't
expecting. Or if you at all familiar with a lower level form of
programming, signals and signal handlers act almost exactly like
interrupt service routines that a hardware device driver would handle.
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
