On Jan 2, 2006, at 11:52 AM, Roy T. Fielding wrote:
It would be feasible to build up the pending request in a structure
other than the request_rec, so that ap_read_async_request() can
operate on, say, an ap_partial_request_t instead of a request_rec.
My preference so far, though, has been to leave the responsibility
for knowing how to parse request headers encapsulated within
the request_rec and its associated "methods."
Maybe you should just keep those changes on the async branch for now.
The rest of the server cannot be allowed to degrade just because you
want to introduce a new MPM. After the async branch is proven to be
significantly faster than prefork, then we can evaluate whether or
not the additional complications are worth it.
"Significantly faster than prefork" has never been a litmus test for
assessing new features, and I'm -1 for adding it now. A reasonable
technical metric for validating the async changes would "significantly
more scalable than the 2.2 Event MPM" or "memory footprint
competitive with IIS/Zeus/phttpd/one's-competitive-benchmark-of-choice."
The bit about degrading the rest of the server is a wonderful sound
bite, but we need to engineer the httpd based on data, not FUD.
Brian
