Thanks Andrew...
Andrew Langmead <[EMAIL PROTECTED]>
05/29/2004 05:24 PM
To: Ranga Nathan <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Re: [Boston.pm] Completing processing before
SIGHUP
On May 27, 2004, at 7:17 PM, Ranga Nathan wrote:
> Say SIGHUP is received and the program has to complete what it is
> doing
> before reacting to the HUP signal. Is this possible? Or can the
> program
> enter into a state where it does not accept HUP signal until it
> reaches a
> quiet point, such as sleep()?
>
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.
Thanks, I do appreciate you teaching me how to fish. This has always been
the hallmark of Perl community.
The examples are all in C, but that should be of
little matter. Once you can determine if and how an application tells
the OS to block signals, then figuring out the perl interface to it is
a relatively trivial second step.
Some options you have:
You can use POSIX::sigprocmask to block or unblock the SIGHUP signal
during your critical portions. If the SIGHUP was sent, it will be
delivered to your application as soon as you unblock it.
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.
If you set a signal handler, be aware of the issues and history around
perl's signal handling:
Before perl 5.8, perl's signal handler could lead to all sorts of
application failures if tripped. They could occur anywhere, including
the the middle of memory allocation calls within the interpreter. A
signal that occurred at the wrong time could cause a program to crash.
The close to safest things you could do would be to have a handler that
would be to simply change an already allocated integer variable from
one value to another.
This is good. I am running Perl 5.8.
In 5.8, the signal handling changed dramatically. It is now safer, but
not quite as immediate. Signals that are tripped are handled internally
by the interpreter, and then between each statement, it is checked if
any signal handlers need running. This means that perl statements that
might take a long time to execute wouldn't be interruptible any more.
In 5.8.1, an environment variable "PERL_SIGNALS" was added to allow
people to ask for the pre-perl5.8 behavior.
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
