Saju Pillai wrote:
On 01/03/06, *Paul Querna* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Greg Ames wrote:
> 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.
Can you tell us what was the reasoning behind merging the event thread
and the listener thread ? A seperate event thread implies that the
listener threads could serialize for accept() for platforms that need
serialized accept(). The event thread never needs to accept() - it only
needs to check for read/write/close events. ( or the platforms that
event mpm runs on - don't need serializing of accept ?)
Because the Event MPM requires a moderm OS with a newer-epoll/kqueue
type thing, none of our supported operating systems require the use of
an accept lock :)
-Paul
