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.
I'm currently attacking 1. and 2., but only on windows at the moment.
I'll add patches and reports into bugzilla later...
Rainer
Lutger wrote:
Justin Johansson wrote:
Eldar Insafutdinov wrote:
Steve Teale Wrote:
On Fri, 19 Feb 2010 16:41:20 -0500, g wrote:
I tried to get some attention for this problem again a couple of weeks
ago (see the "special treat" thread), and everyone who replied said
"yes, we really need this", but Walter does not want to go there.
Is it really true? That's a big shame. Being able to define and use
plugins in a clean cross-platform way is on of the essential features of
big software packages that D aims at to be used in. The solution to this
problem should really be a top priority, at least I have hoped so.
Yes it is really true.
You would have read of my dyna-link saga four posts above yours
and, reiterating, that sadly was the final show-stopper for me
to continue to using D.
At the risk of asking a dumb question, what is the major roadblock? Is it in
the GC? Does it require changing the runtime only, or is it also required to
make changes in the compiler (backend)?
