On Sat, Sep 16, 2006 at 08:31:54PM -0400, Sam Tregar wrote:
> On Sat, 16 Sep 2006, Dean Arnold wrote:
>
> >I think your best bet might be to work with the DBD::mysql maintainers
> >to implement some driver-specific nonblocking versions of
> >execute/prepare (and maybe fetch), as well as support for
> >'out of band' cancel.
>
> That's an interesting idea.
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.
On the server-side the query may be left running on databases that
don't detect disconnects (which I think still includes mysql).
A minor problem with this approach is how to determine the socket file
descriptor. For drivers that don't/can't make the socket fd available,
it requires checking which fd's are open before and after the connect.
Kludgy but effective.
> 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?)
Would be nice to generalise it. There was talk sometime ago (perhaps on
dbi-dev) of extending the DBI api along these lines:
$id = $dbh->{SessionId};
$dbh->kill_session($id);
Would certainly be simple for me to add to the DBI. Then it's just a
simple matter of getting the drivers to implement it :)
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.
Tim.
