On 01/03/06, Greg Ames <[EMAIL PROTECTED]> wrote:
Saju Pillai wrote:

> 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.

hmmm?

in event.c::process_socket()

if (cs == NULL) {           /* This is a new connection */
     cs = apr_pcalloc(p, sizeof(conn_state_t));
[...]
     cs->state = CONN_STATE_READ_REQUEST_LINE;

>   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.

I want to walk thru this with gdb.  obviously you've been studying the code and I've been
away from it for too long.


my bad ... The core create_connection hook does ...

 c->cs->expiration_time = 0;
 c->cs->state = CONN_STATE_CHECK_REQUEST_LINE_READABLE;
 c->cs->c = c;
 c->cs->p = ptrans;
 c->cs->bucket_alloc = alloc;

  return c;

but process_socket in event.c does the explicit

cs->state = CONN_STATE_READ_REQUEST_LINE;

for a new conenction.. Sorry, while reading I jumped from create_connection() to the if .. else code in process_socket which handles the CONN_STATE_CHECK_REQUEST_LINE_READABLE by pushing client socket back to listener.

The worker really does accept() & read() without round trips to listener.

regards
srp


 

> Why do we need an explicit state CONN_STATE_CHECK_REQUEST_LINE_READABLE
> ?.

it is very useful when checking for requests after the first (Keep-Alive)

>  Can the first worker not read() directly from the accepted client ?

sure it can.  that is the intention.

Greg

Reply via email to