apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: cvs commit: apr-util/buckets apr_buckets_mmap.c
Date Tue, 26 Jun 2001 17:50:49 GMT
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


   Cliff Woolley
   Charlottesville, VA

View raw message