On Mon, 02 Jan 2012 20:20:55 +0100, Martin Nowak <[email protected]> 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
