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
