D hates to be dynamic linked

[Rainer Schuetze]

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)?