apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Mon, 11 Jun 2001 21:11:22 GMT
On Mon, 11 Jun 2001, Roy T. Fielding wrote:

> 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,

I suppose that makes sense.

> one for moving data to a preallocated buffer

Except for the "preallocated" part, plain old read() fits the bill.  I
would say that's good enough, but I'm currently on a mission to get rid of
as many malloc's as possible.  So let's just suppose for a moment that we
decided to implemented something new:

I guess what you're asking for is a "read_into()" function?  I could live
with that.  I don't know what exactly that would do to the brigade, but I
imagine there's some something that could be done.  Let's say we have a
pipe bucket that we have to handle.  If read_into() is called on that
bucket, the brigade is busted unless we morph the pipe bucket
simultaneously and allow the brigade to include a pointer to that
arbitrary data.  But it's hard to morph the bucket in this case, because
the bucket doesn't "own" the storage, and therefore it's hard to know what
bucket type to use.  I guess when the bucket doesn't "own" the storage
that's technically the textbook case for an immortal bucket, but I haven't
yet convinved myself that that will work in this case.  I'll have to think
about this some more...

> and another for setaside using a pool.  The problem with a single
> function is that buffering is very filter-specific.



   Cliff Woolley
   Charlottesville, VA

View raw message