apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: Problems with DSOs and Pools
Date Fri, 18 Aug 2006 00:42:23 GMT
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  

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  


View raw message