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/
