That is certainly less code then Ed's proof of concept -- how uncharacteristic of you :)
Hogging the thread is really what I am concerned about. I assume we can know when threads are bountiful vs. under pressure in our own process (since there is that listener pausing stuff). On Thu, Mar 26, 2015 at 9:23 AM, Yann Ylavic <[email protected]> wrote: > On Tue, Mar 24, 2015 at 1:16 PM, Eric Covener <[email protected]> wrote: >> >> Any thoughts? > > Wouldn't something like this help? > > Index: modules/http/http_request.c > =================================================================== > --- modules/http/http_request.c (revision 1669289) > +++ modules/http/http_request.c (working copy) > @@ -232,7 +232,10 @@ static void check_pipeline(conn_rec *c, apr_bucket > { > if (c->keepalive != AP_CONN_CLOSE && !c->aborted) { > apr_status_t rv; > + apr_socket_t *csd = ap_get_conn_socket(c); > > + apr_socket_opt_set(csd, APR_INCOMPLETE_READ, 1); > + > AP_DEBUG_ASSERT(APR_BRIGADE_EMPTY(bb)); > rv = ap_get_brigade(c->input_filters, bb, AP_MODE_SPECULATIVE, > APR_NONBLOCK_READ, 1); > @@ -245,6 +248,8 @@ static void check_pipeline(conn_rec *c, apr_bucket > } > else { > c->data_in_input_filters = 1; > + > + apr_socket_opt_set(csd, APR_INCOMPLETE_READ, 0); > } > } > } > -- > > This is an immediate poll() though, not with a "fraction of a second" timeout. > We could also apr_socket_timeout_set() something, but I'm afraid it > would be at the expense of other events when nothing is available... -- Eric Covener [email protected]
