Re: [pclasses-devel] SharedLib dtor

[Christian P. <cp...@se...>]

Am Donnerstag 23 Dezember 2004 22:08 schrieb stephan beal:
> Yo!
>
> i'm adding SharedLib.ltdl.cpp (uses GNU libltdl, portable libdl
> replacement) and i noticed this code in SharedLib.dl.cpp:

which other DLL APIs does libltdl support ? i thought we catched every DLL API 
with the existing dl, shl, dyld and win32 implementations !?

> 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.

While this is a problem with the CL architecture .. in general it is not.
In fact, when DLLs are unloaded which register themselves upon loading, they 
should also deregister themselves from the CL.

Anyway for objects created within the loaded DLL you're right, it would be 
unpractial to keep track of ownership and to destroy all instances created 
form within the DLL we're unloading. Do you think it is possible to 
"transfer" ownership of objects allocated in DLLs to the app ?

>
> 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!

This is not a problem. In fact SharedLib owns the pointers one can retrieve 
with the operator[]. If this is documented everything is fine.

> 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.

DLLs have a "init" and "shutdown" function. Maybe the Factory pointers can be 
removed by the shutdown function when unloading the DLL.

> See ya!

Greetings