The two most common uses of signals in relation to the DBI
are for canceling operations when the user types Ctrl-C
(interrupt), and for implementing a timeout using alarm()
and $SIG{ALRM}.
and according to the perlfunc manpage on alarm you would
do something along these lines:
eval {
local $SIG{ALRM} = sub {die "alarm\n";};
alarm($timeout);
$db->execute($query);
alarm(0);
};
if ($@) {
die "Error" unless $@ eq "alarm\n";
#timed out
} else {
#didnt
}
| [reply]
[d/l] |
don't know if there's a built in time out for DBI or not,
but you could try using alarm.
$SIG{'ALRM'} = sub {
print "Time's up\n";
};
# give it 15 seconds
alarm(15);
# dbi calls
# turn the alarm off
alarm(0);
/\/\averick
| [reply]
[d/l] |
gee maverick... our answers are so similar... it's like we know each other, worked next to each other for 8 months, live 3 minutes down the road from each other, and hang out damned near on a daily basis or something! :) now, my question to you about your response... how would you use the alarm going off here to get out of the DBI call going bad... you didn't encase it in a block or anything like that. also, i heard somewhere that it was good to reset alarm handlers at the end of themselves for some reason... can anyone back that up, or is that one of those things i immagined?
update: ok, just out of curiosity... why was this voted down? i mean, no biggie if someone didn't like me having a conversation with mav, that's fine... but i can't understand why this was voted down...
| [reply] |
who are you? what are you talking about?
Ya, your solution is better. 'course I pulled this out of my
head in about 3 seconds, I didn't rogue it from a perldoc page :)
Depending on how I wanted to handle the timeout, I would have probably
ended up with an eval block anyways.
/\/\averick
| [reply] |
Thanks, thats exactly what I needed. Plus, I can use the subroutine to print a nice error message in the HTML output.
| [reply] |