On Wed, Aug 16, 2006 at 05:29:45PM -0400, Garrett Rooney wrote: > Here's a patch to mod_test.c and testdso.c that illustrates the > problem. Note that this is running inside the test framework, so it's > not identical to the case we're talking about, but you should be able > to get the idea from what's there. If we move forward on this I'll > move the code out into a separate program so we can really simulate > the case we're talking about.
It's very easy to create test cases which crash and burn due to pool hierarchy abuse using sockets or hash tables or anything else, without using DSOs. I still don't see why this problem should be considered as anything more than that: abuse of the pool heirarchy by the user-of-APR. Branko says "OK; but pools are a usability problem which needs fixing" (if you'll excuse the liberal paraphrasing ;) - we can have discussions about radical changes to pools and their use in APR; but I don't have much sympathy with adding with some hack to create a "special DSO-holding global pool", or changing how allocation from the real global pool is done, just to workaround a single (if systemic) instance of pool abuse in one application [1]. Regards, joe [1] substitute "application" for "consumer of the APR API" at will
