apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Re: Problems with DSOs and Pools
Date Thu, 17 Aug 2006 15:27:04 GMT
On 8/17/06, Joe Orton <jorton@redhat.com> wrote:
> 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].

So you're saying that it should be impossible to use pools within a
DSO loaded module without either absolute control over when those
pools were created relative to the one that loads the DSO or taking
extreme measures within the DSO to work around the various problems
that can occur when the DSO is unloaded?  I'm sorry, but that seems
really really wrong to me.

-garrett

Mime
View raw message