Linux Dynamic Loading of shared libraries

[Sean Kelly via Digitalmars-d-learn]

On Monday, 10 March 2014 at 11:59:20 UTC, Steve Teale wrote:
>
> Note that there is no call to Runtime.unloadLibrary(). The 
> assumption her is that once the plugin has been loaded it will 
> be there for the duration of the program. If you want to unload 
> it you'll probably have to make sure the plugin object is 
> purged from memory first, and I have not discovered how to do 
> that yet ;=(

A long time ago, Andrei suggested creating a GC interface for 
mapped memory.  I think something similar might be appropriate 
here.  Perhaps the location of instantiated classes could be 
determined by their vtbl pointer?  Then the entire vtbl range 
could be treated as a dynamically allocated struct of sorts, and 
its dtor would queue up a job to unmap the library after 
collection is complete (ie. not immediately, since the order of 
destruction during a collection is undefined).

So... (just thinking out loud) when a library is loaded, you 
basically perform an in-place construction of this LoadedLibrary 
struct on top of the vtbl range.  You'd need an interface similar 
to the "GC tracks memory mapped files" idea to tell the GC to 
track references to this range of memory that lives outside its 
own pool set, and then some kind of post-collection job queue 
that's externally appendable so the LoadedLibrary struct could 
add an unload call when it's collected.  Heck, we could really 
handle all dtors this way, so normal dtors would be inserted at 
the front of the list and special cases like this would be 
inserted at the back.

It doesn't sound tremendously difficult, though we'd need the 
memory-mapped file support API first.  Is there something I'm 
missing that makes this unfeasible?