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

Sam and I came up with this while working on a project together that had the potential to generate very long-running queries. We tried a few other things before doing it this way, and they all had downsides. The potential for trouble when you use unsafe signals with XS code is pretty high. If forking really bothers you, you could do a more complicated approach with a prefork server.

You do mention that you already use the unsafe signals approach. If that's working for you, what more were you looking for?

  • Comment on Re^3: how to timeout an operation under mod_perl (fork?!)

Replies are listed 'Best First'.
Re^4: how to timeout an operation under mod_perl (looking)
by tye (Sage) on Sep 07, 2008 at 16:42 UTC

    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        

[reply]
      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.
[reply]
[reply]

In Section Seekers of Perl Wisdom