Saju Pillai wrote:
I can understand why serializing apr_pollset_poll() & accept() for the
listener threads doesn't make sense in the event-mpm. A quick look
through the code leaves me confused about the following ...
>
It looks like all the listener threads epoll() simultaenously on the
listener sockets + their private set of sockets added to the pollset by
workers.
looks like you are correct.
originally there was a separate event thread for everything but new connections and the
listener thread's accept serialization was the same as worker's. then it seemed like a
good idea to merge the listener and event threads, and it only supported a single worker
process briefly. since there was only one merged listener/event thread in the whole
server there was nothing to serialize at that time. then a few of us grumbled about what
happens if some 3rd party module seg faults or leaks memory and we went back to multiple
worker processes.
Will apr_pollset_poll() return "success" to each listener if a
new connection arrives on a main listener socket ? If so won't each
listener attempt to accept() the new connection ?
I think so, but I'm not a fancy poll expert. Paul?
then the question is how bad is it?
Greg
Greg