On Sun, 17 Sep 2006, Tim Bunce wrote:
For any driver that uses a network socket to connect you could close()
the socket in the signal handler to (relatively) safely timeout.
Should be fairly clean/safe for the db client library state, though
unsafe signals means there's still a chance perl's internal state could
be corrupted.
That doesn't sound quite safe enough to me, frankly. I hate memory
corruption bugs...
Right now I'm putting together
DBIx::Timeout which implements my fork()-based timeout in a reusable
package. Seems to work, although I've learned to expect forking code
to have unexpected bugs which take time to shake out.
It's mysql specific currently, using $id=$dbh->{thread_id} and
do("KILL $id"). (And shouldn't thread_id be mysql_thread_id?)
Yup, I figured other people could send me patches implementing that
for their DBs if they were so inclined, but a DBI solution would be
even better!
Also, rather than fork each time you need a timeout it would be nice to
be able to have a single 'watchdog' process and use some form of fast
IPC to tell it when to be active (passing the timeout to use and
relevant session id) and when to be inactive. A pipe would be fine.
But perhaps that could be a new DBIx::Watchdog module. Just a thought.
That's an interesting idea, and worthwhile if DBIx::Timeout was a
bottleneck. That's unlikely in my application since I'm using it in a
case where the query is very likely to be a long one.
-sam
