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
