httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Woolley" <>
Subject Re: buckets
Date Sat, 22 Jul 2000 03:44:49 GMT
>>> 07/21/00 11:01PM >>>

>All of the standard modules should be re-written to take full advantage
>the filters.  Regardless, we need to be able to work with legacy
>modules.  I expect that most modules like mod_autoindex will actually
>create one bucket brigade with a full set of buckets.

Okay, now I'm starting to feel better about this.

>The reason it is wrong to just pass buckets, is that anytime we have to
>append a bucket, we have to traverse the entire list to the end.  This
>wasted time, and all it saves us is a pointer.

As I mentioned earlier.  So since it's only legacy modules that leave
all these extra brigades lying around, I guess we just don't care,

>while (not done) {
>    b = ap_create_rwmem_bucket(...)
>    b->insert(b, ...);
>    ap_brigade_append(...);

Or, as the patch I was going to submit tomorrow would have had it:

bb = ap_create_bucket_brigade();
while (not done) {
   b = ap_create_rwmem_bucket(buf, len, bytes_written);
   ap_bucket_brigade_append_buckets(bb, b);

In either case, passing the brigade makes sense to me now.  See below
for discussion of the bucket creation/insertion.

>If we have to have a bucket when we create the brigade, we can't do

I admit, that part was a fairly hair-brained idea.  I was concentrating
on the other option.  Nevermind.  =-)

>> Also, while I'm thinking about it, I notice that in the patched
>> http_core.c, there are lots of calls to b->insert() right after
bucket b
>> is created.  Wouldn't it be easier to have parameters to the bucket
>> creation function that would create a bucket and populate it at the
>> time?  This seems to make particular sense in the case of bucket

>Yes, it would make sense.  But, it keeps us from creating a list of
>buckets that can be re-used.  ...  The other option is to have both
>functions, but that just makes the API a bit less clean.

Since you say you don't like it, I guess it's not worth me finishing
it... I still would like to be able to do the above (insert the data
without the extra call), but if you say you've got some macro magic to
make it at least look friendlier, that's a start.

The patch wouldn't have stopped you from creating empty buckets, by the
way... you can pass in NULL as the data, and you get an empty bucket,
just like before.  It would look nicer in that case to have a function
you could use that didn't require you to give it a bunch of NULL
parameters.  It'd be a toss up as to whether one function that requires
parameters that are unneeded in some cases would make the API less clean
or having two functions (one would likely just be a wrapper around the
other anyway) would make the API less clean.  I could be convinced
either way.

>This is an optimization that we can make later.  

I don't suppose you could be convinced to like one or the other right
now, then?  Since it's an API optimization, not a speed optimization,
I'd have thought it would be better to work it out sooner than later in
order to facilitate use of the buckets.  I only started on this whole
sequence of questions in the first place because of your repeated
comments in the code that the API needed to be cleaned up...  You tell


Cliff Woolley
Central Systems Software Administrator
Washington and Lee University

Work: (540) 463-8089
Pager: (540) 462-2303

View raw message