Ideas for runtime loading of shared libraries.

[Martin Nowak]

On Mon, 02 Jan 2012 20:20:55 +0100, Martin Nowak <dawg at dawgfoto.de> 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.
>
> martin

Maybe we can agree on how and which shared libraries are initialized for  
threads.
Windows uses DLL_THREAD_ATTACH to do initialization.
So probably we should settle to these semantics.

  - Loading a shared library will do initialization if it's a new library.

  - A newly started thread will initialize all shared libraries currently
    loaded in the process.

  - Threads already running won't be able to access shared libraries
    loaded by another thread.

This has some limitations when using worker threads but it gets rid
of runtime loader hacks.

martin