perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Förtsch <>
Subject Re: [PATCH 2.0.5 futex] Fix to Children stuck on futex problem
Date Wed, 07 Mar 2012 10:15:36 GMT
On Sunday, 04 March 2012 10:29:45 SalusaSecondus wrote:
> Broken behavior:
> 4 threads, 2 free interpreters
> 1: A (1,1)
> 2: A (2,0)
> 3: W
> 4: W
> 1: P (1,1) B
> 2: P (0,2) <-- No broadcast because there was an available interpreter
> prior to this putback.
> 3: A (1,1)
> 3: P (0,2) <-- No broadcast because there was an available interpreter
> prior to this putback.
> (Broken)

I am not quite back to full working condition yet. So, I can't test the patch.

Your analysis seems correct, good catch, thanks! I was wondering about that 
piece of code, too, when I saw it first. I think the original author of the 
function forgot about the signaling before the unlock operation at the end of 
the function. Your patch is better because it does not matter where the signal 
is sent in a critical section. So, is saves one line of code.

To conceive a test case is quite complex but feasible and worth the effort. 
The way I'd try to go is:

1) introduce a new vhost with a separate interp pool with exactly 2 

2) implement a handler that simply sleeps (select undef, undef, undef, 
$timeout) for a short period of time (~0.5 sec)

3) write a test case that issues 4 parallel requests as described above by 
SalusaSecondus. You won't be able to use Apache::TestRequest here or even LWP.
If you put a small delay between the requests, say 0.1 sec, then you should 
even be able to predict which request will hang.

4) see what happens. With the broken system one of the requests should hang 
forever. Ideally, the test client would abort the request and continue after a 
few seconds.

Thanks again,
Torsten Förtsch

Need professional modperl support? Hire me! (

Like fantasy?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message