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 Mon, 14 Aug 2006 18:55:49 GMT
On 8/14/06, Joe Orton <jorton@redhat.com> wrote:
> On Fri, Aug 11, 2006 at 12:42:32PM -0400, Garrett Rooney wrote:
> > The timeline for this sort of thing looks like this:
> >
> > 1. Create application pool (global scope).
> > 2. In another global pool open up a DSO.
> > 3. Call a function defined in the DSO, passing in your application pool.
> > 4. The function inside the DSO registers a cleanup on the application pool.
> "don't do that" would be the obvious (if flippant) answer.  Can you not
> provide some interface for the DSO to clean itself up before it is
> unloaded?  e.g. the DSO could register a cleanup on the DSO-owning-pool
> which will kill any other "global" cleanups it might have registered?

That means that any call into the DSO needs access to the DSO owning
pool, and maybe more disturbingly, needs to have special support for
being built and run as a DSO.  This code can be either linked into the
application or dynamically loaded, and it would be nice if there were
as few differences as possible between the two.  I'm not to hot on the
idea of going back and making every cleanup function inside code that
might be loaded as a DSO capable of being killed when the DSO is
unloaded, especially since that implies that we'll potentially have to
run these cleanups before the pool they were allocated in is
destroyed, so cleanups will run before the objects they're associated
with is invalidated.  That seems weird to me...

I'm really just hoping for a way to make DSO loaded libraries just the
same as any other library, if they require a whole lot of backflips to
use reliably, that seems like a problem to me.


View raw message