On 30.12.2014 16:35, Ivan Zhakov wrote:
> Just to make things clear. The thorough review was already provided.
> In short, subpools are not a solution for the root cause of the
> problem being discussed.
It strikes me that the root problem is amazingly similar to the issue we
had with pool lifetimes and locking in the implementation of DB_REGISTER
support in the BDB back-end (that one was my bug). At the time, I
believe we found that no possible pool usage pattern could avoid bad
interaction with reference-counted objects in pools, given the way pools
currently work in APR.
This is going to be a problem with any long-lived cache that depends on
pools that are created outside our control, as is the case with
HTTPd/mod_dav_svn, where pool lifetimes in general are completely
unpredictable. Combined with unpredictable request patterns and even
less predictable data patterns (since repository content is completely
outside our control), this makes pools amazingly unsuitable for
cross-request caches. Even the lifetime of global pools is unpredictable
because we don't control global pool destruction order.
Given that our API is what it is, I can see no alternative to fixing the
way the caches work. Reference counting only works when you have
complete control over the lifetime of both the cache and the referrer.
-- Brane
Received on 2014-12-30 17:03:30 CET