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
