-----Original Message-----
From: Jonathan Leffler [mailto:[EMAIL PROTECTED]
Sent: 03 November 2006 22:30
On 11/3/06, Jay Hannah <[EMAIL PROTECTED]> wrote:
> Oops. I noticed my versions were behind. I upgraded DBI and DBD::Informix.
>
> I'm still getting the same behavior (14.3 seconds to time out), so I'm
> still curious about what might be going on.
CSDK probably uses alarm itself - for connection timeouts, no less - so
your attempt to use alarm at the same time is likely to cause confusion
somewhere.
You could probably track this with the equivalent of truss (strace on
Linux?), looking for alarm system calls in the output. You'd probably be
able to identify your own alarm(2) call; you might have to work harder to
identify which other alarm() calls are made before you see SIGALRM fire.
Oracle has a similar issue with timing out, see perldoc DBI "Signal
Handling and Canceling Operations" and also
http://search.cpan.org/~lbaxter/Sys-SigAction/dbd-oracle-timeout.POD.
The recommended solution for Oracle works fine with Informix too:
__START__
use Sys::SigAction qw( set_sig_handler );
$timeout = 3;
eval {
my $h = set_sig_handler( 'ALRM', sub { die "TIMEOUT" ; } );
alarm $timeout;
$dbh = DBI->connect(...);
alarm(0);
};
alarm(0);
if ( $@ ) {
if ( $@ =~ m/^TIMEOUT/ ) {
...
}
}
__END__
