httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <>
Subject Re: event_mpm and poll()
Date Fri, 03 Mar 2006 14:54:12 GMT
Paul Querna wrote:
> Saju Pillai wrote:
>> Greetings,
>>  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.

Yep. Looking at it in a slightly different way, poll (and select) maintain poll state in the
user address 
space. The state of each polled fd must to be communicated to the kernel on each and every
call to poll. If 
you want to change the poll state (add or remove an fd in the pollset), poll needs to unblock
in the kernel, 
return to user space, and the user space code updates the pollset, then poll is called again.
Lots of 
user/kernel context switches, lots of data flowing across the user/kernel boundary, lots of
complexity to 
enable a user thread to unblock the poll when the poll state needs to change. Very bad for

> KQueue/EPoll both allow a second thread to insert pollfds into the 
> pollset, while a main thread is still polling.  
KQueue (and similar implementations) maintain poll state in the kernel. A user thread can
make calls into the 
kernel to modify that poll state at the granularity of a single fd. No need to constantly
communicate all the 
poll state across the user/kernel boundary on each poll event.

> 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.
> -Paul

View raw message