Saju Pillai wrote:
On 02/03/06, *Greg Ames* <[EMAIL PROTECTED]
<mailto:[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 :)
I don't want to be too discouraging, but why only using poll(), and why
only with 2.0?
They both seem like steps backwards :)
-Paul
