On Wed, Nov 14, 2001 at 10:05:18PM -0800, Brian Pane wrote:
> Based on Cliff's suggestion, this patch introduces an apr_mmap_dup()
> function that's used to setaside mmap buckets without having to
> memcpy the content.
Cool.
> 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...
> Instead, apr_mmap_dup() lets the caller
> specify which of the two apr_mmap_t structs--the original one
> or the new one--is the owner of the mmap (and is responsible
> for destroying it).
Hrm. It would have been really nice to use apr_pool_is_ancestor(), but I
could see a case where you have disjoint pools:
A
/ \
B C
And you're trying to transfer ownership from B to C.
>...
> --- srclib/apr/mmap/win32/mmap.c 2001/06/27 22:07:24 1.6
> +++ srclib/apr/mmap/win32/mmap.c 2001/11/15 05:45:58
> @@ -62,10 +62,15 @@
>
> #if APR_HAS_MMAP
>
> -static apr_status_t mmap_cleanup(void *themmap)
> +APR_DECLARE(apr_status_t) apr_mmap_cleanup(void *themmap)
> {
Why is this APR_DECLARE'd now? And why the function rename?
In fact, doesn't this change the cleanup to a pascal-style function, and
thus not able to be used as a cleanup callback?
>...
> +APR_DECLARE(apr_status_t) apr_mmap_dup(apr_mmap_t **new_mmap,
> + apr_mmap_t *old_mmap,
> + apr_pool_t *p,
> + int transfer_ownership)
> +{
> + *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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
