Re: event_mpm and poll()

[Saju Pillai]

On 02/03/06, Greg Ames <[EMAIL PROTECTED]> wrote:

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.

Cool.

Where can I see this code ? I looked through trunk & 2.2.x branches from the web but the oldest event.c uses epoll()/kqueue().

I was looking to see if I could hack up a async worker like mpm using poll() on 2.0. A look at your code will help a lot :)

regards
srp



 

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