On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote:
> On dbi-users... I responded to Tim Bunce's most helpful suggestions as
> follows... He suggested Sys::SigAction as name. Since the module is all
> about wrapping up system (POSIX) sigaction() calls, I like it!
>
> 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.
The Sys::Signal docs suggest the key feature is "with the added
functionality of restoring the underlying signal handler to the
previous C function, rather than Perl's". Perhaps perl didn't do
that before.
Um, or perhaps the only way to do that from perl is to use local()
but there are times where local() doesn't provide the right lifespan.
Either way your Sys::SigAction is sufficient. The only thing it's
lacking that Sys::Signal has is the automatic restoration of the old
value when the object is destroyed. It would be trivial to add a
variant of sig_set_action() to do that for those that want it.
Something along the lines of:
sub sig_set_action_auto_restore {
my $class = shift;
return bless sig_set_action(@_), $class;
}
sub DESTROY {
shify->sig_set_action();
}
Tim.
