apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Mon, 11 Jun 2001 20:44:28 GMT
On Fri, Jun 08, 2001 at 09:42:42PM -0400, Cliff Woolley wrote:
> It's not just a "bit of byte stuffing within a buffer" at all.  The pool
> has some lifetime associated with it.  The reason for passing in a pool is
> to be able to say to the buckets code "this resource should live at least
> THIS long".  That also implies that some data structures (not data!) will
> need to be copied into that pool, ie an apr_file_t or an apr_mmap_t.  It
> would only work to just pass an arbitrary storage pointer if we actually
> copied all of the data represented by the bucket into that buffer, and
> that's not the idea at all.

But that's not thinking at a wide enough scope.  There are lots of reasons
why I chose the analogy of "bucket brigades" for the original design, but one
is that we want to put the "fire" out.  Web applications are very sensitive
to latency.  The only way to get both network-efficient packets and avoid
suffering from unnecessary latency is to prevent more than a specific
amount of data from getting stuck in the filter chain.  Sometimes that
isn't possible due to the nature of a filter (batch-like processing),
but in general we do not want to setaside anything but raw data, and only
then when it is less than 4KB.  [Not 9000 bytes -- 4KB is more than
sufficient to justify a network write.]  Even a cached file handle is
better copied to memory at that point if doing so avoids the need to
mutex a bunch of code.

Maybe what we need is two functions, one for moving data to a preallocated
buffer and another for setaside using a pool.  The problem with a single
function is that buffering is very filter-specific.


View raw message