Ideas for runtime loading of shared libraries.

[Jacob Carlborg]

On 2012-01-02 20:20, 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.
>
> martin


- Initializing module infos
- Initializing exception handling tables
- Running module constructors
- Initializing TLS

Then also unload all this when the library is unloaded.

On Mac OS X, can't "_dyld_register_func_for_add_image" be used? Then it 
will work, hopefully, transparently for the user. D libraries used by C 
wouldn't need any different handling. Because they will be linked with 
druntime it can initializing everything with the help of 
"_dyld_register_func_for_add_image".

-- 
/Jacob Carlborg