httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Problems with EOS optimisation in ap_core_output_filter() and file buckets.
Date Mon, 16 Feb 2009 13:13:49 GMT
On Mon, Feb 16, 2009 at 12:34:26PM +0100, Ruediger Pluem wrote:
> On 02/16/2009 11:07 AM, Joe Orton wrote:
> > The call to:
> > 
> >             ap_save_brigade(f, &ctx->b, &b, ctx->deferred_write_pool);
> > 
> > in that code path should result in the FILE bucket and the contained fd 
> > being dup()ed.  (Though if that is failing, you wouldn't know because of 
> > the lack of error checking)
> 
> Are you sure?
> 
> apr_file_setaside does not dup the fd.

Oh, good point.  This feels like one of those cases where some core 
assumptions about the filtering/bucket API start melting away underneath 
me.

Why is it invalid use of the filtering/buckets API to close the file 
after sending the FILE-containing brigade up the filter stack?  

It seems counter-intuitive to me that *anything* you do after the 
ap_pass_brigade() call should make a difference to what was passed up 
the filter stack.  But I suppose this is the case; even most of the 
memory-backed bucket types don't duplicate referenced memory in the 
setaside method.

I've always thought of FLUSH as a *hint* towards the desired network 
behaviour.  To say a FLUSH is required here is to model FLUSH as a 
*mandate* on the bucket/object lifetimes.  That's a huge difference.

Indeed, if I go read some API docs in the headers, which is always good 
for a laugh/cry moment:

apr_bucket_eos_make => "All filters should flush at this point."

apr_bucket_flush_make => "This indicates that filters should flush their
   data.  There is **no guarantee** that they will flush it, but this is 
   the best we can do."  (my emphasis)

So EOS is a better flush then FLUSH, right?

Regards, Joe

Mime
View raw message