Akins, Brian 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.
The trouble with this is that all you need to do to wedge one of the worker threads is to promise to send two bytes as a request body, and then send one (or zero), then hang. Ideally any async implementation should be 100% async end to end. I don't believe that its necessary though for a single request to be handled by more than one thread. Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
