Paul Querna wrote:
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.
Yep. Looking at it in a slightly different way, poll (and select) maintain poll state in the user address
space. The state of each polled fd must to be communicated to the kernel on each and every call to poll. If
you want to change the poll state (add or remove an fd in the pollset), poll needs to unblock in the kernel,
return to user space, and the user space code updates the pollset, then poll is called again. Lots of
user/kernel context switches, lots of data flowing across the user/kernel boundary, lots of complexity to
enable a user thread to unblock the poll when the poll state needs to change. Very bad for performance.
KQueue/EPoll both allow a second thread to insert pollfds into the
pollset, while a main thread is still polling.
KQueue (and similar implementations) maintain poll state in the kernel. A user thread can make calls into the
kernel to modify that poll state at the granularity of a single fd. No need to constantly communicate all the
poll state across the user/kernel boundary on each poll event.
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.
Yep
-Paul
Bill
