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

Reply via email to