Quoting Garrett Rooney <[EMAIL PROTECTED]>:
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.
This way, there would be no need to have another API call and things
would work with no crashes. I'm just not sure if the dlopen()
semantics as explained for Linux apply to other OSes and their DSO
support...
--
Bojan
