On Wed, 14 Nov 2001, Brian Pane wrote: > I gave up trying to do full reference counting semantics for > duplicates of apr_mmap_t, because I couldn't find a suitable > pool to own the locks that would be required in a threaded > implementation. Instead, apr_mmap_dup() lets the caller > specify which of the two apr_mmap_t structs--the original one > or the new one--is the owner of the mmap (and is responsible > for destroying it).
Yeah, that could work. I'l have to think on it a bit to see if I can come up with any cases where it won't work, but it seems okay so far in concept [haven't looked closely at the implementation yet]. > The patch includes a change to mod_file_cache to create a non-owner > copy of the mmap for the bucket brigade to use, so that the mmap can't > get unmapped by any code other than mod_file_cache itself Why is that necessary? The original mmap from mod_file_cache is owned by mod_file_cache and is allocated out of cmd->pool. cmd->pool definitely lives longer than r->pool. I guess the problem is that cmd->pool is not an ancestor of r->pool, right? It's disjoint (kind of a great-uncle or something ;). FEH. Is there some clean way we can allocate the mmap out of a better pool than the cmd->pool [like pchild or something]? The less work we do at request time, the better. I guess this wouldn't be the end of the world, though. --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
