Ideas for runtime loading of shared libraries.

[Walter Bright]

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.