[pclasses-devel] SharedLib dtor

[stephan b. <st...@s1...>]

Yo!

i'm adding SharedLib.ltdl.cpp (uses GNU libltdl, portable libdl 
replacement) and i noticed this code in SharedLib.dl.cpp:

SharedLib::~SharedLib() throw()
{
	dlclose((void*)_handle);
}

i strongly recommend removing that dlclose()!

In my experience that's a Bad Idea because it is *impossible* for us to 
track all DLLs/objects brought into the system by any given dlopen(). 
Each is free to call arbitrary code which can use other - non-dlopen() 
- techniques for opening additional DLLs. By extension, it is 
impossible for us to accurately know what dlls we later need to close. 
What this means is random crashes whenever a SharedLib goes out of 
scope. The 'man dlopen' docs imply that dlclose() is safe, but in my 
experience it's not.

Let the OS shut down the dlls when the app exits - that is the only 100% 
safe thing to do.

Consider this code, where a client innocently uses SharedLib to open a 
DLL:

void myfunc() {
 SharedLib lib( "/my.so" );
...
}

after myfunc exits we have a major problem: we are expecting to be able 
to get at types loaded via that dll. We only used SharedLib to open the 
DLL for us, not expecting it to shut down the DLL when the SharedLib 
object dies!

The current dtor WILL break the classloading layer if the CL uses 
SharedLib to open DLLs. Remember that the CL model doesn't require any 
symbol lookups - it only opens a DLL and then ignores it, expecting the 
types in the DLL to register themselves with the classloader. Their 
factories exist in DLL-space, and shutting down the DLLs leaves our 
Factory with handles pointing to closed DLLs.

See ya!

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts