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 Fri, 18 Aug 2006 00:57:32 GMT
On 8/17/06, Bojan Smojver <bojan@rexursive.com> wrote:
> Quoting Garrett Rooney <rooneg@electricjellyfish.net>:
> > 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.
> This is probably a stupid suggestion, but here it goes nevertheless...
>  From what I can tell from the manual page of dlopen() on Linux, every
> time a new DSO is loaded, a reference count is increased, but the
> shared object file is loaded only the first time. So, the OS actually
> doesn't do the job multiple times, but only once. Meaning, loading the
> same DSO multiple times isn't really going to load the new DSO, but
> will give an already existing handle. So, to really unload the DSO,
> the apr_dso_unload() must be called the same number of times as
> apr_dso_load() (unless someone's been calling dlopen()/dlclose()
> directly in the meantime - which is something we cannot deal with).
> If we were to have the "magical" DSO pool (access to which would have
> to be serialized via a mutex) and have a hash in there of which DSOs
> have been loaded, we could simply ignore any subsequent requests to
> apr_dso_load(), serve the pointer we have in the hash and increase our
> own counter. The dso_cleanup() can then become a no-op in terms of
> dlclose(). It would only decrease the reference count, kept in the
> hash. Once the reference count comes to zero, we still don't do
> dlclose() in dso_cleanup(), but rather leave to the next
> apr_dso_load(). If user counts on things being the same after that
> point, then this would still be a problem, but I'm hoping that's not a
> requirement.

That is in fact what the Subversion code currently does.  The problem
is that you need to create the global DSO code sufficiently early in
the application's lifecycle to ensure that it lives longer than all
other pools during global shutdown.  If any other pool will outlive it
you risk that pool having callbacks set on it that call functions
defined in the DSO.


View raw message