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
