Re: Unloading shared libraries loaded by require()

[dptr1988 <junk_mail@...>]

On Thursday 03 February 2011 6:24:32 pm Drake Wilson wrote:
> Quoth dptr1988 <junk_mail@dptr1988.mooo.com>, on 2011-02-03 18:13:45 -0800:
> [paragraphs reflowed]
> > That's basically what I did, but the C shared library still seems to
> > be loaded in the memory and pmap still shows that it's there.
> > 
> > "unrequire" successfully removes the Lua visible references to a C
> > shared library, but it doesn't actually unload it from the
> > memory. From what I can tell, ll_unloadlib() is only called when the
> > userdata with the shared library handle is GC'ed ( which usually is
> > when the Lua state is closed, since the userdata is in the registry )
> 
> The underlying problem is not as easy to solve generally as one might
> think.  You cannot safely unload a C library until all ways of calling
> any C functions in that library and all pointers to memory that might
> be managed by that library are gone.  But lua_pushcfunction and kith
> aren't normally called with any Lua handle to the C library, AFAIK, so
> the GC can't directly see such references, and forcing the matter is
> risking a segfault in the future if any other piece of code, say,
> detected the library was loaded and stashed away a reference to one of
> its functions behind a pile of closures.
> 
> Obviously there are cases where this is much more predictable, but it
> makes sense that unloading C libraries is a dangerous thing that would
> require poking around to do.
> 
> > Peter
> 
>    ---> Drake Wilson
> 
> 
What if Lua was changed so that it records a reference to the shared library for each C closure that is created and if a rule was made that all C functions that dereference untrackable[1] pointers from other shared libraries keep at least one reference to the shared library ( through a C closure from that shared library ) for the whole time they use the untracked pointer? I don't think that the requirement to keep a reference to the shared library when using an untrackable pointer is that harsh, since ( from what I can tell ) the interfacing between two seperate shared library based modules in Lua is fairly limited and the requirement of keeping a reference to the other shared library is fairly easy to do. 

Unless I'm missing something, that would track all exports from a shared library making it safe for the shared library to fully managed by the Lua GC and unloadable just like Lua based modules are.

Assuming that it would be possible to change Lua to record a reference to the shared library each time a C closure was created, what would be the disadvantages of doing it? The extra load put on the GC to track C function closures should be minimal, as most C modules don't export many functions.

Peter

[1]: Untrackable by the Lua GC, such as embedded in a userdata or a pointer as a lightuserdata ( which is asking for trouble IMO, since lightuserdata can't by type checked ).