httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: httpd-2.0 STATUS
Date Fri, 12 Jan 2001 20:15:27 GMT
On Fri, Jan 12, 2001 at 02:32:40PM -0000, rbb@apache.org wrote:
>...
>   +    * Mod_autoindex is still causing too many buckets and too many bucket
>   +      brigades to be created.  We need to improve the way the old ap_r*
>   +      functions interact with buckets.  This is being tabled until after
>   +      the beta.
>   +          See MSG: <Pine.LNX.4.21.0101111403150.1557-100000@koj>

I had a whacky idea about this a little while ago.

Consider: our main problem is the allocation of the brigade and the
transient bucket. We use the transient bucket to defer copying until
necessary. That is an important part, so we shouldn't lose that.

Consider: ap_r* are NOT re-entrant. Across all the functions.

Possible answer: "allocate" a brigade and a custom bucket type in the
request_rec. ap_r* would fill in some values and pass the brigade down. If a
set-aside occurs, then the custom bucket simply copies into heap bucket or
whatever. During a set-aside, the brigade we pass won't be used because the
code doing the set-aside can't know the pool the thing was allocated in, so
we don't have to worry about the fixed structure in the request_rec. Since
ap_r* aren't reentrant, again, we don't have to worry about the fixed
structs in the request_rec.

The custom bucket type (Apache-specific probably, but I could see it
possibly going into apr-util, too) would have a no-op destroy. The rest of
the bucket would be just like the transient bucket type.


What the above means is that ap_r* is no longer a factor in bucket/brigade
optimizations. We have a low-cost solution to transform from old-style into
the bucket-style. Then we just work on improving bucket operations.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message