For a brand new client connection, why should there be 2 exchanges between the listener thread and the worker thread before the request is actually read ?
The client socket is accepted() and passed to a worker thread which runs the create_connection hooks and marks the connection in the CONN_STATE_CHECK_REQUEST_LINE_READABLE state. This is again pushed back to the listener which will poll it for readability and mark it as CONN_STATE_READ_REQUEST_LINE if it's readable. A worker now grabs this client and performs the actual read.
Why do we need an explicit state CONN_STATE_CHECK_REQUEST_LINE_READABLE ?. Can the first worker not read() directly from the accepted client ? Is it to avoid a DoS attack where clients open connections but don't send a request ?
In cases of kernel (like freebsd) that support "http_ready" filters won't the accept() only succeed once a request line is already available for reading ? i.e on bsd (maybe) we can get better benchmarks if accept() & read() at the same time.
regards
srp
On 01/03/06, Paul Querna <[EMAIL PROTECTED]> wrote:
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
