Re: Possible module for 'safer' signal handling....
I've just requested registration of and uploaded: ftp://pause.perl.org/incoming/Sys-SigAction-0.01.tar.gz Thanks to all who helped in discussing this. Lincoln
Re: Possible module for 'safer' signal handling....
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! Lincoln, A slow reply to the thread in general: yes please. This module would be very handy, coding up an esoteric distinction between 5.8 5.6 that would take me at least the nine months you took to find, and probably more. This module wpould be a splendid thing. All power to your coding elbow. Mx.
Re: Possible module for 'safer' signal handling....
* Lincoln A. Baxter [EMAIL PROTECTED] [2004-01-12 10:02]:
On Sun, 2004-01-11 at 15:50, Tim Bunce wrote:
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.
Actually, I think it is much worth pursuing, given this:
* Lincoln A. Baxter [EMAIL PROTECTED] [2004-01-11 15:19]:
This module is almost as convenient to use as the above:
#timeout a system call:
use POSIX ':signal_h' ;
use SignalHandler qw( set_handler );
eval {
local $SIG{ALRM};
set_handler( 'mypackage::mysubname' ,SIGALRM );
alarm(2)
#... do something you want to timeout for instance:
$dbh = DBI-connect( dbi:Oracle:$dbn, $usr, $pwd
,{ AutoCommit=$self-auto_commit()
,RaiseError=1
,PrintError=$self-print_err()
} );
alarm(0);
};
#perl clears the handler here... because of the local dec above
alarm(0);
if ( $@ ) ...
IMO it would be much neater not to have to separately localize
$SIG{ALRM} but to have restoration optionally done by your module
on request. I believe the clearest way to handle the syntax would
be a check for context in sig_set_handler() and returning an
object that auto-restores the signal in question on destruction
only if the context is not void.
That way people could write
my $restore = sig_set_handler( ... );
when they want it undone and simply
sig_set_handler( ... );
when they do want the change to persist until explicit change.
--
Regards,
Aristotle
If you can't laugh at yourself, you don't take life seriously enough.
Re: Possible module for 'safer' signal handling....
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.
Re: Possible module for 'safer' signal handling....
At 10:09 + 1/12/04, Tim Bunce wrote:
On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote:
eval {
local $SIG{ALRM} = sub { ... };
}
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();
}
I'm not sure whether this is relevant here, but I seem to recall a
bug reported sometime in the past 3 weeks about signals not being
restored at the right time when using eval. You might want to p5p
archives for that.
Liz
Re: Possible module for 'safer' signal handling....
On Mon, 2004-01-12 at 05:46, Elizabeth Mattijsen wrote:
At 10:09 + 1/12/04, Tim Bunce wrote:
On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote:
eval {
local $SIG{ALRM} = sub { ... };
}
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();
}
I'm not sure whether this is relevant here, but I seem to recall a
bug reported sometime in the past 3 weeks about signals not being
restored at the right time when using eval. You might want to p5p
archives for that.
Thanks Liz for the note. I have found the discussion, and have down
loaded the fellows test script. Unfortunately it does NOT reproduce the
bug on my system (current gentoo) with perl 5.8.0 I am building a 5.8.2
perl now to see what that does.
I think I will see if I come up with an object implementation the resets
the handler in on object destruction. I will then modify his script to
see if the problem persists with Sys::SigHandler, using scope based
resets.
Re: Possible module for 'safer' signal handling....
On Mon, 2004-01-12 at 04:18, A. Pagaltzis wrote:
IMO it would be much neater not to have to separately localize
$SIG{ALRM} but to have restoration optionally done by your module
on request. I believe the clearest way to handle the syntax would
be a check for context in sig_set_handler() and returning an
object that auto-restores the signal in question on destruction
only if the context is not void.
That way people could write
my $restore = sig_set_handler( ... );
when they want it undone and simply
sig_set_handler( ... );
when they do want the change to persist until explicit change.
I have come to the same conclusion. It has an additional benefit that
you can explicitly reset things by just undeffing the reference to the
returned object if thats what one wanted to do.
If sig_set_action could handle such an object, I would kill two birds
with one stone. I think I'll head in that direction.
Today I got the code working with perl 5.005 through 5.008. and I am
building 5.8.2 now so I can test with that. Interestingly, with
versions of perl earlier than 5.8, could not get the POSIX::sigaction
routine to behave, so I implemented it under the covers, but just
setting $SIG{name}. Which got me identical behavior across all three
versions.
This discussion has been most helpful.
