On Tue, Jul 7, 2009 at 12:54 PM, Akins, Brian<brian.ak...@turner.com> wrote: > This is how I envisioned the async stuff working. > > -Async event thread is used only for input/output of httpd to/from network* > -After we read the headers, we pass the request/connection to the worker > threads. Each request is "sticky" to a thread. Request stuff may block, > etc, so this thread pool size is configurable and in mod_status, etc. > -any "writes" out of the request to the clientare passed into the async > thread. This may be wrapped in filters, whatever. > > *We may allow there to be multiple ones of these, ie one for proxies, or > have a very well defined way to add watches to this. > > This is a very simplistic view. I was basically thinking that all conn_rec > "stuff" is handled in the async event thread, all the request_rec "stuff" is > handled in the worker threads.
Right, but I think the 'waiting for X' while processing is a very important case, it can get you to a fully async reverse proxy, which opens up lots of possibilities.
