httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF EITO <ruediger.pl...@vodafone.com>
Subject Re: cache: the store_body interface
Date Tue, 31 Oct 2006 10:44:16 GMT


> -----Ursprüngliche Nachricht-----
> Von: Joe Orton  
> Gesendet: Dienstag, 31. Oktober 2006 11:27
> An: dev@httpd.apache.org
> Betreff: Re: cache: the store_body interface
> 
> 
> 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.

Thanks, for pointing out. I missed those two types. But this changes nothing
on my remark that 2) is effectively 3) with just having the buffers
packaged into buckets and brigades. So 3) seems to be the clearer 
and more "honest" interface to me.
Furthermore it does not require provider programers to understand
buckets and brigades :-).

> 
> > >>> 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.

Ok, sounds like 4) is a disguise of 1) :-).
As I thought that 1) was bad and 2) is the same as 3) with 3)
having the better interface my only remaining vote is 3).

Regards

Rüdiger


Mime
View raw message