On 02/18/2009 11:16 AM, Joe Orton wrote: > 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.
Yes, I don't know how MMAP would work with this, so dup might be a bad approach regarding this. In any case it looks like it would cause a lot of trouble until working stable again :-) > > 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 There is still a nasty issue with the trunk code that can cause you to run out of FD's as the new non blocking core output filter has some trouble setting aside the file buckets to the correct pool (it puts them in the connection pool which is too long living and bad). See thread starting at http://mail-archives.apache.org/mod_mbox/httpd-dev/200901.mbox/%[email protected]%3e I admit that I lost momentum on this, but this definitely needs to be fixed. > these options are pretty distasteful but (1) seems like the only > feasible route. What do you think? I guess at least for the moment (1) is the way to go exactly for the reasons you stated. Regards Rüdiger
