Wow. Spawning a new child process for every time you want to run a max-10-second interaction with your database?

That sounds like the type of thing that motivated the creation of mod_perl and thus probably not something you want to do much from mod_perl.

That module's documentation does link to an alternative, DBI's docs on Canceling Operations. But it is also correct to note that doing this will likely cause stability problems. We do it but we have to implement seppuku code whereby the process can usually recognize when it has lost its mind (because all DBI calls fail after that point -- which requires the processes in the layer above to know how to retry requests) and to kill itself when that happens.

We also ask the database to timeout requests and that doesn't appear to introduce instability but it also appears to not always work (queries certainly sometimes run quite a bit longer than the specified maximum time-out). This, of course, varies based on how well such time-outs are supported by your particular database.

So, yeah, it is a mess.

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?