On Tue, 26 Jun 2001, Greg Marr wrote: > >Why not simply reference count the MMAP/file handle? > > I came up with these questions after sending this suggestion: > > Where would the reference count go? > - Instead of having an MMAP/file handle, the apr_*_t would have to > point to a structure containing the MMAP/file handle, and a reference > count. This memory for this structure could not come from any pool > with a shorter lifetime than the server itself. It would likely have > to be directly apr_malloc'ed.
That's a good question... it very well might have to be malloc'ed and then free'd when the last reference gets deleted, much as the bucket destroy functions have to do with the apr_bucket_shared_delete() stuff. > What about locking? > - For setaside, there should be no other threads knowing about the > buckets. The bucket data is just moved to another lifetime, not > another thread. As long as the apr type isn't given to another > thread, there should be no locking issues. While an MMAP *bucket* must not exist in more than one thread at a time, it is entirely possible that the apr_mmap_t *in* that bucket might be in more than one thread at a time, one set of buckets per thread. mod_file_cache does this. I've been working on a way to let the file buckets handle files opened with an APR_XTHREAD flag, which indicates that the file descriptor is shared among multiple threads. I'm guessing the APR mmap code would have to get a similar flag. At that point, you only have to lock accesses to the refcount if the apr_mmap_t was created in APR_XTHREAD mode. --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
