Ideas for runtime loading of shared libraries.

[Martin Nowak]

On 01/02/2012 08:20 PM, Martin Nowak wrote:
> I think that I'll defer the support for runtime loading of shared
> library (plugins)
> in favor of getting linked shared library support done now.
> There are several issues that require more thoughts.
>
>   - Per-thread initialization of modules is somewhat tricky.
>     Doing it in Runtime.loadLibrary requires knowledge of shared library
> dependencies
>     because different threads might share dependencies but this is not
> provided by libc/libdl.
>
>   - D libraries used by a C library should provide proper runtime
> initialization
>     even if the C library is used by a D application.
>

I now think we should do the initialization directly when loading, even 
though that might cause deadlocks in certain scenarios. It would solve 
all mentioned initialization issues. This will also serialize 
initialization on the loader mutex but I don't expect this to become a 
performance issue.

>   - Getting symbols through mangled names is difficult/unstable.
>

ref T loadSym(T)(string fqn);
void loadSym(T)(string fqn, out T res);

T loadFunc(T)(string fqn);
void loadFunc(T)(string fqn, out T res);

auto lval = loadSym!int("std.foo.bar");
loadSym("std.foo.bar", lval);

auto fptr = loadFunc!(bool function(string) pure)("std.foo.func");
loadFunc("std.foo.func", fptr);

>   - Libraries might not be unloaded as long as GC collected class
> instances still exist because
>     finalization fails otherwise.
>

We should extend the GC to allow marking and finalizing of foreign 
memory. This is needed for shared memory too.

// gc.gc
// ...
void trackRange(void* p, size_t sz, void delegate(void*, size_t) dg);
// ...

auto p = malloc(1000);
GC.trackRange(p, 1000, (p, sz) => .free(p));

> Any ideas or use-cases for plugins are welcome.
>

Still holds.

> martin