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. 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.
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.
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
