Runtime.loadLibrary() and unloadLibrary() on POSIX.

[alexrp]

Requires: dlang/dmd#941

[bithavoc]

+1

[MartinNowak]

We need a full blown library initialization.
We also need a shared runtime instead of a GC proxy.

[alexrp]

So what is the plan for these functions?

[bithavoc]

@alexrp ++
@dawgfoto what do you mean, will this patch work or not? :)

[dnadlinger]

I think the issue is that the patch itself is correct, but not enough to smoothly support shared libraries on Posix, because all kinds of stuff will still break behind your back. Martin already did some work on this in the branch at his repo he linked, but as far as I know, there is still some more to do – you might want to join forces.

[MartinNowak]

Linking against shared libraries will work soon but loading shared libraries at runtime
will still take a while. There are two major technical issues to solve.

• Runtime.unloadLibrary will probably have to go. Due to GC one cannot deterministically free all references to a loaded library. The latest idea for this was to put the address range under control of the GC and let him release the library.
• There is no solution yet for per-thread initialization when you load a C library at runtime that depends on a D library. Basically we need to traverse the dependency DAG of a library but the only feasible solution I found was to poke around in the dlopen handle.

[bithavoc]

I get it, that's like others GC'd/managed environments works(AppDomain.Unload in the CLR) and that sounds like a good plan for the future. However, (and this is just a thought) I think that a partial implementation of this feature that at least let the developer load D shared libraries would be very useful.

IMHO, this will be used mostly to load plugins, plugins will modify the environment and do random stuff. From the application point of view it's easier to just restart the process in order to reload the new "catalog" of plugins.

Developers can use dlopen for C shared libraries and loadLibrary for D shared libraries. I don't think unloadLibrary is that necessary at this point, it's always better to just restart the process. In the future, if there will be an implementation of unloadLibrary, it will just mark the library to be unloaded eventually by the Runtime/GC.

So I would vote for a partial implementation of 'loadLibrary' and defer 'unloadLibrary' until we can afford the unload libraries in a safe way by a shared Runtime, etc.

Again, this is just a thought.