httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: Filter I/O take 3.
Date Fri, 16 Jun 2000 22:38:29 GMT
> Date: Fri, 16 Jun 2000 14:40:05 -0700
> From: Greg Stein <>
> > Note that various folks have pointed out that doing async I/O only on
> > read (and perhaps only when reading/waiting for the first header of a
> > request) brings a lot of bang for the buck (I don't mean that
> > literally, Ralf).  
> Can't do this either. Consider the various calls to ap_get_client_block()
> which are (again) scattered down "inside" modules which then rely on
> context which is defined by the stack.
> Apache moving to an async model simply looks impossible, without a **HUGE**
> overhaul in every facet of its operation. At that point, it just won't be
> Apache. I could see a case where a module can say "I can deal with async;
> here is my API to call for read/write availability." To support that,
> though, would still require a huge revamp on the Apache-side of the
> equation.

I think it would be fairly straightforward and non-intrusive to use an
async read to keep from tying up lots of threads in keepalive:

  In ap_process_http_connection(), before calling ap_read_request()
  have a way to detect whether or not there is data from the network
  already available in the underlying BUFF.  If no data available,
  return to the MPM code, which will start an async read request with
  the BUFF's internal buffer as the place where the data should land.
  This worker thread then looks for work to do on other connections.

  (Possible optimizations: if no data in BUFF's buffer, call poll() or
  select() to see if we would block; maybe we always want to block for
  the first request on a connection)

  When the MPM is notified by the kernel (hopefully with the conn_rec
  address as user data), the MPM maps the request to a worker thread,
  which calls ap_process_connection() again.  It has data this time so
  it does ap_read_request() and processes the request and again, just
  before ap_read_request(), makes the decision about whether to commit
  to processing another request or returning back to the MPM.

  Every second or so, the MPM would cancel the async read requests for
  connections that have exceeded the keepalive timeout and close their

As for async I/O elsewhere...  order of magnitude more trouble

Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message