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