On Mon, 30 Apr 2001, Cliff Woolley wrote: > This is definitely better than the leak. =-) And nothing says that the > cache can't apr_mmap_delete() the MMAP associated with the master file > bucket as long as refcount==1 (ie, there are no requests using that > file/mmap currently in progress) if it decides it has too many MMAPs > laying around. It's possible that the file will be re-MMAPed by a later > request, but the MMAPs could be just cycled through in an LRU fashion. > This would leak one palloc'ed apr_mmap_t in the cache's pool, however. > It's a trade-off. Which is better: having potentially as many MMAPs open > as you have file handles cached, or growing the size of the cache pool by > sizeof(apr_mmap_t) each time you delete and recreate an MMAP for a file? > In either case, this is still much better than the current situation (the > leak), which has both problems, only worse... ;-]
I had an idea for fixing the leaking of the apr_mmap_t structure at lunch, and thought I'd throw it out here for discussion. One way around this is to have a variant of apr_mmap_create() that accepts an existing apr_mmap_t structure and "fills it out", rather than preemptively palloc'ing a new apr_mmap_t and using that one. If we had that, then the apr_file_t could contain a pointer to the apr_mmap_t for that file. The first time the file is MMAP'ed, the apr_mmap_t that's allocated is hung off the apr_file_t's pointer. The apr_mmap_t has a flag in it that indicates "active" or not. When the mmap is apr_mmap_delete'd, the flag is set inactive. If the file gets re-MMAP'ed, the apr_mmap_t created before is reused and set active again. I don't know if this is useful or not, but it's one idea. Just a thought. --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
