On Mon, Feb 16, 2009 at 03:12:11PM +0100, Ruediger Pluem wrote: > On 02/16/2009 02:13 PM, Joe Orton wrote: > > 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 guess this is not needed in most cases and is not done for performance > reasons. But maybe we can change the setaside for file buckets to do > an additional dup on the fd.
The choices seem to be: 1) declare the FLUSH to be be necessary in this case as you said originally ;) - and document appropriately 2) rewrite/reinvent all the setaside methods to dup/copy as appropriate 3) declare the core output filter broken and fix it Of these (2) and (3) will presumably have some negative performance impact though I'm not sure to what degree. Not sure (2) is even going to be possible, e.g. with MMAP buckets, scary stuff. Looking at the cray-zee non-blocking core output filter on the trunk, it will setaside with wild abandon unless it hits a FLUSH. I think all these options are pretty distasteful but (1) seems like the only feasible route. What do you think? Would be good to get some more opinions on this. Regards, Joe
