On 1/2/2012 11:20 AM, 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. - Libraries might not be unloaded as long as GC collected class instances still exist because finalization fails otherwise. - Getting symbols through mangled names is difficult/unstable. - D libraries used by a C library should provide proper runtime initialization even if the C library is used by a D application. Any ideas or use-cases for plugins are welcome.
My idea for this is straightforward. A D plugin should use a C interface. That means, for example, that a D plugin should NOT pass GC allocated references to its caller. Only malloc'd data should pass between the plugin and its caller.
The D plugin could still use the shared druntime.so, and could share that usage with the D caller of the plugin.
