Thanks Brian.
It's commited.
On Thu, 2001-11-15 at 20:35, Brian Pane wrote:
> 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 thread
On Fri, 16 Nov 2001, Greg Stein wrote:
> > 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.
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
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 thre
