httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject Re: event_mpm and poll()
Date Wed, 01 Mar 2006 19:46:55 GMT
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.

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.


View raw message