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
