Do as little as possible, the more stuff you do the more chance that things are happening at an inconvieniant time for your application... interrupted syscalls etc
Basically, just set a flag that your application will check and reset next iteration through...
my $running = 1;
$SIG{HUP} = sub { $running =0 }
while ($running){
do_stuff();
}
the handler only signals the outside that next time through it should stop...
@_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;
| [reply]
[d/l]
[select] |
Well, it depends. Are you running with safe signals or not? Safe signals were introduced early in the 5.8.x series. It basically means that delivery of a signal is delayed till the next "op" - which means that when the handler is run, the perl internals are in a consistent state. It's, from a perl POV, safe to do almost anything. The disadvantage is that the signal may arrive during a long running system call, which means it may take a long time for your signal to be handled. Unsafe signals, the old default, were delivered immediately. From a C POV (and since perl is written in C, this is important), you can only do a handful of things safely; you shouldn't call non-reentrant function, and, importantly, you shouldn't malloc memory. Unfortunally, almost anything you do in Perl may cause perl to malloc memory (including looking at a variable). | [reply] |
| [reply] |
Thanks, reading perlipc very much helped me.
Actually I was attempting a connect inside the signal handler and I went blinking because, at some times the HUP signal itself was not passed to the program(means, not reached the signal handler), I read the below URL(after perlipc:signals) and it was helpful,
http://www.madore.org/~david/computers/connect-intr.html
but I am still unsure about using connect inside a signal handler, can anyone guide me.
| [reply] |