Re: ltdl bugs

[Jeff Squyres]

On Apr 3, 2005, at 11:33 AM, Ralf Wildenhues wrote:

> [snipped much explanation]
> I'll try to rephrase:  You may actually do what you intend in
> lt_dlexit(), because that is (like MPI_Finalize) final in the sense,
> that after as many lt_dlexit's as lt_dlinit's we may completely shut
> down our stuff and free every data we own.

Ah.  That would be perfect.

You're right that in my case, I don't care if the memory is freed in 
lt_dlclose() -- I only care at the end of time (i.e., after 
lt_dlexit()).

> You may _not_ do this in lt_dlclose(), however, because the user may
> issue another lt_dlopen() of the very same module (which may be NULL, 
> or
> "foo.la" made resident), which in fact is already open.
>
> Combine that with the fact that I simply don't know what will happen
> then for any of the system-specific module interfaces we implement.
> Thus, I regard this as disallowed.

That works.  I'll go mull on this and try to come up with another patch 
(for lt_dlexit() this time).  May take a few days; I had a window of 
opportunity this morning.  :-)

However, you mentioned something a mail or two ago:

> Maybe we should explicitly add to the docs:  "If another part of your 
> application uses a module loading interface (such as dlopen()) without 
> wrapping it through libltdl, then the behavior is undefined."

You probably want to add this regardless of the what happens with a 
patch to fix this memory leak or not.  We take very much the same 
approach in my MPI implementations: if you go outside the library's 
interface and potentially mess with any of the data or communication 
channels that the library is using, you do so at your own risk.

--
{+} Jeff Squyres
{+} address@hidden
{+} http://www.lam-mpi.org/