Hello There, > 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?
That's a fact of *NIX life I am afraid: KILL is unstoppable (ignore), as is SIGSTOP - they provide the user/admin with a "surefire way of either killing or stopping a process" --Stevens. And, as catching these would also enable you to ignore them, you cannot do that either! I did not read the whole thread, but if you are doing more than just handling error conditions/froceful termination from the kernel, you should be aware that signals hanve slightly different behaviors across the *NIX spectrum. This is particularly relevant if you take to blocking them, or if you want them to interrupt/restart the so called "slow system calls". -Federico _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish Muad'Dib of Caladan (Federico L. Lucifredi)- [EMAIL PROTECTED], http://www.lucifredi.com ----- Original Message ----- From: "Ranga Nathan" <[EMAIL PROTECTED]> To: "Boston List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, June 02, 2004 0:34 Subject: Re: [Boston.pm] Completing processing before SIGHUP > 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 > _______________________________________________ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
