perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe M. Chiasson <>
Subject Re: COND_WAIT in modperl_tipool
Date Mon, 23 Apr 2007 04:59:41 GMT
On 28-Mar-07, at 12:06 PM, Torsten Foertsch wrote:
> Hi,
> is there a reason not to use APR mutex and condition variables in  
> the tipool
> implementation but instead Perl's COND_... and MUTEX_... macros?

I know I wondered about that exact same thing a long time ago, and if  
serves me right, it was an early doug'ism. Think APR wasn't quite  
there yet
at that time or something.

But as far as I can tell, it doesn't really make much of a difference.

> The reason I am asking is that after some heavy load generated with  
> ab over a
> GBit link I have seen request timeouts and what is worse apache  
> processes
> hanging around not accepting connections. Then I patched mod_perl/ 
> mod_status
> to report the waiting in COND_WAIT via the scoreboard and saw there  
> were some
> requests hanging in this state after all traffic has been finished.
> The really bad thing about that is that the hanging process is  
> alive for the
> master apache. So, it's share of the scoreboard is blocked and  
> MaxClients is
> practically lowered by ThreadsPerChild.

That's strange, and could indicate some bug somewhere. Something not  
by the tipool's usage rules and causing these hangs. Any change your  
showed you where this might be hapenning ?

> I have then changed the tipool implementation to use  
> apr_thread_cond_timedwait
> with a timeout of 0.5 sec instead of COND_WAIT. The problem seems  
> gone.

Hrm, that sounds like you just worked around one problem, most likely  
another one ;-)

> I know the problem lies probably not in mod_perl but in the pthread  
> lib on my
> Linux (NPTL 2.5). But maybe it is saver programming not to wait  
> forever. The
> more as it is not determined in what order threads are awakened by a
> pthread_cond_signal

Can you tell where these child were stuck in COND_WAIT ? I'm curious  
about what
code path was jamming.

Philippe M. Chiasson     GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5       m/gozer\@(apache|cpan|ectoplasm)\.org/

View raw message