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 -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
