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 name-mangling problem here. Don't want 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
