On Sun, 2004-01-11 at 15:50, Tim Bunce wrote: [snip]
> It might also be worth adding some mechanism to integrate with Sys::Signal > http://search.cpan.org/src/DOUGM/Sys-Signal/Signal.pm I took a look that this. It is little bit of perlxs glue which uses perl's internals to set signal handlers, and have them restored when the object returned gets destroyed as it goes out of scope. It does not help us with our problem however, as it just does what perl does. I see no real benefit to this over: eval { local $SIG{ALRM} = sub { ... }; }; Perhaps there was a time when the above trick was not well known, and Sys::Signal was implemented to do that. After looking at the truss and strace outputs for the way the above code works, I would say that Sys::Signal is pretty unnecessary. > And given the existance of Sys::Signal in the Sys:: namespace > I think it would be reasonable to call your module Sys::SigAction. GREAT idea! Sold! I love it. > Especially if it can integrate with Sys::Signal. Not much help here, > > The sub names set_handler and reset_action names are very generic. > I'd suggest adding a sig_ prefix to both. Yea I was thinking the same thing. > > I'd also suggest swapping the parameter order to make this neater: > > sig_set_handler(SIGINT, sub { > ...code... > }); > Agreed... That's better. > 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 :) Yep... Great suggestions. I will cross post this to module-authors... and respond to followup discussion there. I will return to this thread here when I have something more complete to share. I unless you would prefer I post it to dbi-users. Thanks! Lincoln
