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
