Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of jim@jagunet.com designates
 209.133.199.10 as permitted sender)
Message-Id: <75438C5F-3382-4562-A7AB-BF8ABB8643FA@jaguNET.com>
From: Jim Jagielski <jim@jaguNET.com>
To: dev@httpd.apache.org
In-Reply-To: <ad8a87120810091353h57d578e7k206c05ae492f37c8@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: PR45605 and event MPM
Date: Fri, 10 Oct 2008 08:22:55 -0400
References: <48EBEAB2.1090405@apache.org>
 <ad8a87120810091353h57d578e7k206c05ae492f37c8@mail.gmail.com>


On Oct 9, 2008, at 4:53 PM, Greg Ames wrote:

>
>
> On Tue, Oct 7, 2008 at 7:03 PM, Ruediger Pluem <rpluem@apache.org>  
> wrote:
> I am currently looking at PR45605 (https://issues.apache.org/bugzilla/show_bug.cgi?id=45605 
> )
> and the analysis and the resulting patch in Comment 4 look good to me
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=45605#c4). As  
> worker and event MPM
> are very similar I had a look if and how this patch is applicable to  
> the event MPM.
> I noticed that ap_queue_info_wait_for_idler is quite different in  
> worker and event MPM.
>
> I don't think the problem reported by PR45605 exists in the Event MPM.
>

AFAICT, I don't think so either.

> I had to stare at ap_queue_info_wait_for_idler for a long time back  
> when it could be called by two separate threads.  The unserialized  
> access to queue_info->idlers followed by the unconditional decrement  
> outside of the mutex in that section of code made my head twitch  
> when I thought about races on SMP systems.
>
> The two major improvements in Event's fdqueue are:
>
> * doing the atomic decrement first before making a decision about  
> waiting.  The decrement is visible to other threads immediately.
> * using the negative value of idlers to distinguish between when  
> threads (just the listener today) are waiting for idle workers vs.  
> when all workers are busy but nobody else (the listener) is  
> blocked.  That eliminates a situation where the condition variable  
> is signalled unnecessarily, which happens in the PR scenario.
>

Comparing the 2, it does appear that Event includes improvements that
would benefit Worker and vice versa...