in reply to Re^3: how to timeout an operation under mod_perl (fork?!)
in thread how to timeout an operation under mod_perl

The original poster was looking for something. I was not looking for something, I was pointing out what is probably the major drawback to the solution you offered and pointing out alternatives and some of the major drawbacks of them.

But, no, none of them work very well, in my experience. It is rather sad that we can't have signals interrupt DBI while just preventing the signal action from bubbling up to the next higher level of abstraction until that level of abstraction is at a safe point for it to be interrupted. Perl's implementation of "safe signals" just never interrupt a long-running DBI call. That should be considered a bug to be fixed (without having to resort to "unsafe signals").

- tye        

  • Comment on Re^4: how to timeout an operation under mod_perl (looking)

Replies are listed 'Best First'.
Re^5: how to timeout an operation under mod_perl (looking)
by perrin (Chancellor) on Sep 07, 2008 at 16:54 UTC
    Sorry tye, didn't notice that the name had changed before I replied. Having safe signals that could interrupt DBI would be ideal. This is common enough that maybe DBI actually needs special handling for timeouts built in.

        Retrying on EINTR? How annoying! What is the motivation for that? A DBI call seems like the perfect place one would want to interrupt something with a signal (queries can take surprisingly long to run and long-running queries can cause problems for other users of the database so wanting to time-out queries seems an obvious desire). I'd expect such retrying to at least be optional (or to at least not retry on SIGALRM).

        - tye