httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: buckets
Date Tue, 18 Jul 2000 01:49:55 GMT
Hmmm, new-httpd must have been constipated today...

>   What it all boils down to is that the ap_bucket_list type doesn't
>really seem to be needed.  Why can't ap_bucket just have a prev and next
>pointer, thus eliminating ap_bucket_list altogether?  Even the name of
>ap_bucket_list is misleading because it's not really a LIST, it's a list
>NODE.  A brigade is a LIST... it has a head and a tail.  So why is the
>intermediate type even necessary?  Why not just have a brigade (list)
>contain a bunch of buckets (nodes) which point to one another in order? 
>If we did that, then all my destruction problems would be alleviated
>(currently, it's really easy to forget to destroy the ap_bucket_list
>node and just destroy the ap_bucket, leaking some memory in the
>I know that they're only there because they were in Roy's original
>design... what's the benefit of them?  What's the downside to nixing
>them that I'm not seeing?

I was going to mention the same thing last week but ran out of time.
The original idea of separating buckets from the bucket brigade
mechanism was so that an entire bucket structure could be cached.
Thus, the bucket manipulators would not be allowed to change the
values within the bucket structure, so prev and next pointers in there
wouldn't work.

However, when I was looking over Greg's stuff (which just passes the
front-most bucket), I hit that difference and started thinking critically
about why the brigade type is needed at all.  It might be better to
treat the bucket structure as unique to the stream and only the
bucket data as cacheable.  It has the advantage of vastly simplifying
the access pattern for the filters, since they only have to deal with
one type instead of two.  But what does it mean to "free" a bucket
which is the head of a brigade?  There are lots of decisons there which
need to be made on the basis of how a filter will operate.

OTOH, what that design loses is the ability to "cache" sizing information
within the list structure -- things like front and back pointers (a shortcut
for tail filters), number of buckets (important for determining when a
merge operation is desirable), etc.  The other thing it does is prevent
the filters from running as independent threads, though my experience
has been that independent threading is an overall performance loss due
to the added locking requirements.

So, my current thinking is to go with a simple design for the interface
between filters and put all the data smarts in the bucket ADT and a
"stream pool".  That's most of what is in Greg's stuff, though I'd
separate the bucket code from filters, require that filters inherit the
stream pool from the chain (which causes the allocations to have the
same lifetime as the stream exit-point), implement two "free lists"
within the stream pool (one for buckets and another for bucket-data),
and get rid of any bucket types that do not significantly enhance
performance (like the vsprintf bucket).  I'd then add metadata buckets
and make sure that filters distinguished them from data.  I think we
would then have a useful basis on top of which later performance enhancements
can be added without screwing the filters or them screwing us.

But right now I need to prepare another presentation. *sigh*


View raw message