On Sun, Jan 11, 2004 at 02:32:34AM -0500, Lincoln A. Baxter wrote: > On Sat, 2004-01-10 at 05:18, Tim Bunce wrote: > [snip] > > > > > I will share the solution when I have it figured out. In fact, would be > > > willing to give you a README.signals file to include in DBI docs if I > > > get it figured out. > > > > If you figure it all out I'll not only add your write up to the > > DBI.pm pod, I'll use it as the basis for the relevant part of the > > 2nd edition of the DBI book :-) Your name will be in lights! > > OK, I got it. And I _will_ write it up. But in the meantime, I have a > little module, I have written to solve this problem in a way that works > for 5.6.x and 5.8.x transparently. I'm thinking of > putting up CPAN...
Yes, yes! > I will send a message to module-authors after this > message. Currently (for convenience I am calling this SignalHandler.pm > (attached). (Gotta come up with a name). It includes the beginning of > POD, which demonstates how to use set_handler() with it defines. > I'm thinking of adding a timeout() function which would take a sub ref > and a timeout value, and execute the sub with a SIGALRM timeout wrapped > around it. But this solves the problem raised by this thread, and which > has prevented me from upgrading to perl 5.8 at Fleet for the last 9 > months. I still need to test for the availability of sigaction() with > %Config, (and perhaps), provide a signal() based implementation if > sigaction() is not found. It might also be worth adding some mechanism to integrate with Sys::Signal http://search.cpan.org/src/DOUGM/Sys-Signal/Signal.pm And given the existance of Sys::Signal in the Sys:: namespace I think it would be reasonable to call your module Sys::SigAction. Especially if it can integrate with Sys::Signal. > I hope this helps. Looks like it! > package SignalHandler; Some suggestions... > use POSIX ':signal_h' ; > use SignalHandler qw( set_handler reset_action ); > my $oldaction = set_handler( 'mypackage::mysubname' ,SIGINT ); > ... do stuff non-interupt able > reset_action( $oldaction ,SIGINT ); The sub names set_handler and reset_action names are very generic. I'd suggest adding a sig_ prefix to both. I'd also suggest swapping the parameter order to make this neater: sig_set_handler(SIGINT, sub { ...code... }); Getting more esoteric now... reset_action is just a slightly optimized version of set_action. I think reset_action could be dropped and set_action changed to only do POSIX::SigAction->new if not called in a void context. (And be called sig_set_action :) Tim.
