On Mon, 24 Jun 2002, Bill Stoddard wrote: > Yack... just noticed this too. This renders the fd cache (in > mod_mem_cache) virtually useless. Not sure why we cannot setaside a fd.
You can. The buckets code is smart enough to (a) take no action if the apr_file_t is already in an ancestor pool of the one you're asking to setaside into and (b) just use apr_file_dup() to get it into the requested pool otherwise to handle the pool cleanup/lifetime issues. It's the core_output_filter that's doing an apr_bucket_read() / apr_brigade_write() here. Presumably to minimize the number of buffers that will have to be passed to writev() later. That could be changed pretty easily, and the mmap/memcpy/munmap/writev would go away. Note, however, that since you can only pass one fd to sendfile at a time anyway, delaying the sending of a FILE bucket is pretty pointless if you're going to send it out with sendfile later anyway. What would be better is to mmap the file and hang onto the mmap to pass a bunch of mmap'ed regions to writev() all at once. For cache purposes, that just means that all you have to do is consider the size of the files you're dealing with, and if they're small, use MMapFile instead of CacheFile. If we then got rid of the apr_bucket_read/apr_brigade_write in the core_output_filter and just saved up a brigade instead, you'd be set. --Cliff
