Rainer Schuetze wrote:
Hi,
as I'm also hitting some problems with DLLs, here are some issues that I
am now aware of (sorry, can't tell for linux shared objects, but I guess
the situation is similar):
1. For D2, there is a major blocker with DLLs loaded after intialization
on XP because of no TLS support from the OS. There is a simple
workaround for single-threaded application (just setting FS:2c to a
pointer to _tlsstart), but I'm considering a full emulation of the TLS
initialization.
2. No multi-threading support: I've added a function to std.thread that
allows adding a thread to the Thread.allThreads array, so it can be
called from DLLMain/THREAD_ATTACH. That way the GC can suspend these,
and allocations from different threads don't trample onto each other. Is
there anything else needed for full multi-threading support?
My patch is currently D1/Win32 only, but should not be too hard to
extend to other platforms. Attaching to already existing threads is a
bit harder, though, and it might not always be desired, because these
threads might never call into D-code.
3. To try things out, I am playing around with the mydll-example, and it
shows some quirks that you need to get around: the implementation-file
for the DLL needs to use a file name different from the module name,
because you need another file specifying the exports. Unfortunately this
cannot be the di-file created from the source, because it contains two
much information that will cause references to symbols not actually
exported.
Maybe some command line switch is needed to just write the exports into
the di file without any implementations. Even better: import the
implementation file, but don't create unnecessary references. (I think
it's the module-initialization that's been called because of the import
- maybe some modifier to the import could remove it).
4. The documentation on the website states, that you should use
DATA PRELOAD SINGLE
in the def-file. That probably is still there as a historical note to
win 3.1, it will cause different processes to trample on each others
data segments. This has caused a few hours of debugging, so please
remove it, so others don't fall into the same trap. The mydll-example
does not use the statement.
5. To share gc-collected objects between different DLLs, a common
phobos-DLL seems necessary. Extracting the GC into a separate DLL and
using the proxy-mechanism to attach any other client-DLL to it seems
feasable, but are there other things that need to be shared between
different phobos-instances? What about exception-handling?
I'd say, if there is a way to put all public symbols into a def-file,
then compile phobos into a DLL and create the import library and use
this instead of a static library. The multi-threading-issue for DLLs
needs to be solved before, though.
Hi Rainer,
Congrats. Sounds like you are giving the problem a lot of thought.
Just regarding the public symbols though, I hazard a guess that you
might run into a mangled-name problem here. Don't won't to put a
damper on your effort though; just a forewarning that this might be
an issue. Perhaps someone else who knows about exporting DLL
symbols might be gracious enough to chime in.
Cheers
Justin
