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
