[LA.pm] Problem with FastCGI under Apache 2

[Benjamin J. Tilly]

"Kevin Scaldeferri" <kevin+lapm at scaldeferri.com> wrote:
> 
> On Feb 9, 2006, at 3:21 PM, Benjamin J. Tilly wrote:
[...]
> The usual place that you see this is when you're calling something 
> like a database client, which does some signal masking internally.  
> In that case, the signal will be blocked until the database call 
> finishes.

The place where I encountered this looks exactly like that.

We needed to set unsafe signals for DBI's test for a stale database handle to work.

> I don't know exactly what's going on with your situation, but I 
> would definitely recommend that you _NOT_ use unsafe signals.  The 
> thing is, they're not safe.  There are really bizarro things that 
> can happen to perl's internal state as a result of using them.  
> It's not as nice as perl just segfaulting if something bad happens. 
>   You can end up with silently incorrect behavior after the 
> delivery of an unsafe signal.  I hope this example will scare you 
> away from ever using unsafe signals in an important application:
> 
> http://kevin.scaldeferri.com/blog/2004/03/04/unsafe.html

I know the problems, but I'll continue using them unless you can offer another way to break out of a call to DBI's connect_cached within a fixed (fairly short) time.

With unsafe signals, if something makes existing database handles become invalid, we lose our currently executing pages and have the possibility of unhappy behaviour until the Apache child dies.  With safe signals we have a guaranteed site outage as requests pile up for mod_perl processes which are trying to figure out whether they have a database handle.

Hopefully nothing invalidates all of our database handles at once.  However I have seen networking bobbles do just that, and I wouldn't want a minor problem to suddenly become a major one.

Cheers,
Ben