apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: [PATCH] mmap_setaside (with apr_mmap_dup)
Date Fri, 16 Nov 2001 15:16:24 GMT
On Thu, 15 Nov 2001, Greg Stein 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.
> Not sure what you mean here. I don't quite understand how threading comes
> into play. apr_file_t and apr_mmap_t can't be used by multiple threads,
> AFAIK. And I don't think they should either...

Sure they can.  apr_file_t has an APR_XTHREAD flag explicitly for this
purpose (I think apr_mmap_t ought to have one, too, but it doesn't).
*Buckets* can't be shared across threads, but apr_file_t's and
apr_mmap_t's most certainly can and are.  See mod_file_cache.

> > +    *new_mmap = (apr_mmap_t *)apr_palloc(p, sizeof(apr_mmap_t));
> > +    memcpy(*new_mmap, old_mmap, sizeof(apr_mmap_t));
> > +    (*new_mmap)->cntxt = p;
> For the two dup() functions, you can use apr_pmemdup() to simplify this.

I think he probably did this as an optimization because the compiler can
recognize a memcpy with a constant length parameter and make it very fast,
whereas the generalized memcpy() routine is a big ol' bugger.  <shrug>


   Cliff Woolley
   Charlottesville, VA

View raw message