apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH 2] Re: [PATCH] mmap_setaside (with apr_mmap_dup)
Date Fri, 16 Nov 2001 21:53:44 GMT
On Thu, Nov 15, 2001 at 08:35:47PM -0800, Brian Pane wrote:
>...
> When I tried to implement a traditional reference-counting solution
> (all apr_mmap_t's duplicated from the same original share a reference
> count, and the mmap'ed segment is destroyed only when the refcount
> reaches zero), I ran into threading problems with mod_file_cache.
> It's possible for two threads to be doing a dup of the same
> cached apr_mmap_t at the same time--if they're both delivering the
> same statically cached file, and they both end up having to call
> mmap_setaside.  To avoid the race condition here, we'd need a lock
> around the reference count. The lock API requires that we create the
> lock from a pool, but there isn't a really suitable pool from which
> to allocate the lock, given that its lifetime isn't necessarily tied
> to that of a request or connection.

The "suitable pool" is that of the apr_mmap_t itself. Note that the file
cache would be putting that lock into its own long-lived pool.

Not so hard, or I'm missing something :-)

> Fortunately, this whole problem went away when I switched from the
> reference-counted model to the transfer-of-ownership model.  The latter
> doesn't require any locking.

Yah.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message