httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: my ideal resolution to small writes
Date Tue, 23 Jan 2001 04:37:56 GMT
My opinion is that the only reason this is an issue at all is because
the buckets API, as currently implemented, doesn't work the way we
need it to work.  What I would do is simply put all of the coalescing
in the HTTP message filter (and have it do the chunking, rather than
split that task into a separate filter), pass the header fields
through the filter as metadata (so that things like charsets and
content lengths can be handled properly), and create a new

   ap_rwrite_brigade(r, brigade)

function that manages the interleaving of old r_w* calls with the
more efficient brigade writes.  But that would obviously take a
lot of work, and I need to find a way to keep up with e-mail first.

The fault in the current code is in the setaside design.  It should
be setting aside the content whenever the content is too small to
justify a write, and in the process collecting the content into
a large buffer rather than trying to keep the bucket structures.
But implementing that right requires a first-class ADT for buckets
and the removal of all that fricken macro crap that has spread
implementation assumptions throughout the server.

In fact, the first thing I would do if I had the time would be to
toss out every decision made at the "filters meeting" and
reimplement the filters as a simple linked-list stack with statically
allocated buckets (pointing to separately allocated bucket data).

I bet that would be popular.

But, lacking the time, I'd settle for a 2.0 that works.
Both of the proposed solutions are band-aids at best, so just
commit whatever is better than today's HEAD and replace it later
if it turns out to suck as well.  Commit both if that is what
it takes.

And I'd honestly appreciate it if people would stop making grandiose
claims about freezing the API for some or such release.  The API
isn't going to be frozen until it is proven to be stable, which
means when the pressure to change it becomes less than the pressure
to keep it static.  Just generate the bloody tarball and we can
decide afterwords whether or not it is good enough to be frozen.

....Roy

Mime
View raw message