Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <440621B4.9020105@apache.org>
Date: Wed, 01 Mar 2006 17:35:32 -0500
From: Greg Ames <gregames@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: event_mpm and poll()
References: <13c255070603011056s27c2122fl@mail.gmail.com>
 <4405FA2F.6050202@force-elite.com>
In-Reply-To: <4405FA2F.6050202@force-elite.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Paul Querna wrote:

>>  The event mpm expects the apr_pollset backends to be based on epoll() 
>> / kqueue() or Solaris 10 event ports. What are the reasons because of 
>> which poll() is not considered to be suitable for the event mpm ?
>>  
>> Is this because of the large number of fd's to be polled and linear 
>> scalability that epoll() / kqueue() provides but poll() doesn't ? Is 
>> there any reason why a poll() based implemenation of event_mpm cannot 
>> be done if some performance degradation is ok ?
> 
> 
> Performance is actually not the core reason.
> 
> The core reason is the thread-safety of the pollset.
> 
> Poll() does not allow a 'main thread' that is polling to get new sockets 
> added to it, without first waking it up.
> 
> KQueue/EPoll both allow a second thread to insert pollfds into the 
> pollset, while a main thread is still polling.  This significantly 
> reduces the complexity, and allows for better performance, because we 
> don't require a Context-Switch to add a client to the main pollset.

Bill Stoddard and I originally used poll().  but there was a problem getting the event 
thread to notice a new descriptor and add it to the pollset in a timely manner.  I added 
some Rube Goldberg stuff to solve that, involving a pipe and extra context switching as 
Paul mentioned.  that was good enough for a proof of concept and shaking out other issues.

but the new fancy poll implementations take care of that, so what is in svn now is much 
cleaner.  worker threads can add a descriptor directly to the pollset and the listener 
thread reacts appropriately even if it is currently blocked.  nice!

Greg