Hi, That sound like one way to go, I want to be very careful with something like this. You speak as if restoring 5.6 behaviour is the best or only way to go. Do you see any other alternatives?
Thanks, Eric At 04:57 PM 9/16/03 +0200, Rafael Garcia-Suarez wrote: >Eric Frazier wrote: >... >> But then I found I was using 5.8.. Thanks to a guy on comp.lang.perl.misc I >> know that there is a change in how signals are handled, they call it >> deferred signal handling because Perl now is suppose to wait until the >> Interpeter is in a safe state. As I understand it this might avoid some >> things like core dumps or other errors related to dieing while trying to do >> something besides dieing. > >Mostly, yes. Look at the perldelta manpage that is distributed with perl >5.8.0, section "Safe Signals". I did read that, it seems kind of misleading. The 5.8 IPC doc was more helpful, but I still didn't get a clear idea how to handle this and the examples are not updated yet. > >If you want to restore the 5.6-ish "unsafe" signal handling, this is not >possible with 5.8.0 :(. But, as it has been acknowledged that this unsafe >behaviour is desirable in some cases, it will be possible with perl >5.8.1. > >You can grab a 5.8.1 release candidate 4 from CPAN : > http://search.cpan.org/~jhi/ >(RC5 should be out in a few days) >and see with it if using unsafe signal handlers solves your problem. >You can enable them with the PERL_SIGNALS environment variable. >Here's the relevant part of the perlrun manpage that comes with perl >5.8.1 RC4 : > > =item PERL_SIGNALS > > In Perls 5.8.1 and later. If set to C<unsafe> the pre-Perl-5.8.0 > signals behaviour (immediate but unsafe) is restored. If set to > C<safe> the safe (or deferred) signals are used. > See L<perlipc/"Deferred Signals (Safe signals)">. > >HTH. > (250) 655 - 9513 (PST Time Zone) "Inquiry is fatal to certainty." -- Will Durant
