httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: cache: the store_body interface
Date Tue, 31 Oct 2006 10:27:12 GMT
On Mon, Oct 30, 2006 at 10:13:09PM +0100, Ruediger Pluem wrote:
> >>> 2) keep the interface as-is, but read buckets in mod_cache and partition
> >>> the brigade manually; only pass a "small" brigade with known-length
> >>> buckets to the provider. (so no morphing and no arbitrary memory
> >>> consumption)
> 
> As far as I can see this small brigade would only contain the following bucket
> types (pipe and file buckets would get morphed due to apr_bucket_read):
> 
> heap transient mmap

Any bucket type which directly represents mapped memory would remain: so 
POOL and IMMORTAL too of those shipped in APR-util.

> >>> 4) change the interface: pass some abstract "flush-me" callback in,
> >>> which the provider can call to pass up then delete the bucket.
> >>> (apr_brigade_flush doesn't quite fit the bill unfortunately)
> 
> Just curious: Why do you think it does not fit the bill? Because it requires
> a brigade instead of a bucket or because we possibly would need to pass the
> filter to it as ctx?

Yes to both :) it would require the provider to move flushable buckets 
into a temp brigade before calling the apr_brigade_flush-type callback, 
and would require passing f->next in somehow as well.  So you get all 
the downsides/benefits of the provider having to know how to be a Good 
Filter, but adding complexity to prevent it from being a real filter; 
smells wrong.

Regards,

joe

Mime
View raw message