httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject async write completion prototype
Date Mon, 10 Oct 2005 06:50:39 GMT
With the batch of commits I did this weekend, the Event MPM in
the async-dev Subversion branch now does write completion
in a nonblocking manner.  Once an entire response has been
generated and passed to the output filter chain, the MPM's
poller/listener thread watches the connection for writability
events.  When the connection becomes writable, the poller
thread sends it to one of the worker threads, which writes
some more output.

At this point, the event-handling code is ready for testing and
review by other developers.

The main changes on the async-dev branch (compared
to the 2.3-dev trunk) are:

1. ap_core_output_filter: rewrite to do nonblocking writes
    whenever possible.

2. core, http module, and mod_logio: removed the generation
    of flush buckets where possible.

3. request cleanup and logging: the logger phase and
    subsequent destruction of the request's pool are now
    triggered by the destruction of an End-Of-Request
    bucket in the core output filter.

4. event MPM: asynchronous handling of CONN_STATE_WRITE_COMPLETION.

There are several more things that need to be fixed in order
to make the asynchronous write completion useful in a
production release of httpd-2.x:

- The main pollset in the Event MPM currently is sized to
   hold up to one socket descriptor per worker thread.  With
   asynchronous keepalives and write completion, the pollset
   should accommodate many descriptors per thread.

- The logic for starting more child processes, which Event
   inherited from Worker, is based on assumptions about
   the number of concurrent connections being equal to
   the number of threads.  These assumptions aren't valid
   for a multiple-connections-per-thread MPM.

- Similarly, there may be some changes needed in the
   flow control logic that the listener thread uses to decide
   whether it can do an accept.

- The scoreboard probably needs a redesign.

- It may be valuable to have a separate thread pool to
   run handlers that do arbitrarily lengthy processing, such
   as mod_perl and mod_php.


View raw message