httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <...@dotat.at>
Subject Re: [PATCH] Filter registration.
Date Fri, 28 Jul 2000 18:54:58 GMT
"Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU> wrote:
>
>>I don't think this is useful because a lot of the data that you put
>>into a bucket has a longer lifetime than only one trip down and up the
>>call stack, and you want to be able to make the most of that property.
>
>That is the data inside the bucket.  The bucket structure itself is
>rarely usable across invocations because of the way filters work -- they
>end up either transforming the data (in which case the bucket goes away)
>or storing the data in a way that is efficient for later processing
>(in which case the bucket will most likely go away).

But then the data has changed too, so you still have the situation
that the lifetime of the bucket is the same as its contents. The same
is true for the bottom filter if it concatenates the buckets when it
saves the contents: the old data and buckets are destroyed and
replaced by new ones. I think that if you keep the bucket and content
lifetimes the same then it will simplify the rules you have to follow
to ensure that buckets are used correctly.

>In some cases it is best to allocate the bucket structure from a
>heap, and in others it is best to allocate it from the stack.  We could
>easily choose either one (provided the allocations come from the right
>pool in the heap case, and provided that the filter calls downstream
>filters on a write for the stack case).  Greg's point, I believe, is
>that it is easier to manage and more efficient on the common case
>for the bucket structure to always be allocated from the stack, or at
>least to assume that is the case within receiving filters.  We then only
>have to worry about managing the lifetime of the data within the bucket.
>Try it and see. 

I'm scared that playing mix-and-match with allocators is a recipe for
confusion and bugs. Perhaps it can be solved by having special bucket
colours for buckets in different places... But I know that allocating
only on the stack is too limiting, and that some of the unpleasant
complexity of C++ is due to the fact that it tries to make objects on
the stack work as well as objects on the heap... Dunno. Let's try it
and see :-)

>It's an interesting idea, but all you are doing is naming the function
>that is set as the free() pointer for the bucket.  Rather than coloring
>buckets by their behavior, we should be coloring them by their interface.
>That is, the significant distinctions between bucket types are:
>
>   how do you read the data within this bucket
>   what are you supposed to do with the data read (metadata vs data)
>   how do you set aside this bucket for the next call

I think that's exactly what I was trying to describe. The paragraphs
you snipped explained the different behaviours of the bucket methods
for the interesting colours, i.e. read and consume as well as free
(which is just a part of the consume method that runs when all the
data has been consumed).

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
464 whipstitch ligament fix

Mime
View raw message