[D-runtime] druntime fixes again break Windows DLL support

[Sean Kelly]

On Apr 20, 2011, at 2:06 PM, Rainer Schuetze wrote:
> 
> I agree. A DLL "connected" to a D app must not do any initialization in DllMain(PROCESS_ATTACH), because it has not received the gc-proxy yet. (There is some code in the proxy to move the ranges to scan to the application GC, but any object created during initialization lives on the wrong heap and will not be scanned or collected.)
> On the other hand a "standalone" DLL must be initialized in DllMain, unless you want to add a lazy initialization check to every export that might get called, waiting for setProxy() being called first or not.

Oh right... I knew I'd thought about this before and found a problem with my last suggestion.  It's the module ctors.  They are run by rt_init(), and if they allocate any memory, that memory won't be scanned by the app's GC for roots.  It's a horrible chicken & egg problem.

> I guess, I repeat myself, but I don't think the GC-proxy mechanism is good enough. What if the DLL creates a thread? The app does not know about the new thread (won't suspend it in a GC collection), the GC does not scan the new TLS data segment of the DLL (it even does not get notified of the apps own new TLS segment). I think, there is more trouble lurking (e.g. socket initialization).

I think there's a comment in the runtime somewhere that says "do something about DLL-created threads someday."  It's solvable via a proxy mechanism similar to the GC, but that approach is so horrible that I've been holding off on doing it.  Is there a problem with sockets as well?

> The best approach I see is to share the complete runtime in a DLL, so any executable or DLL can use shared or unshared memory, threads, etc. as defined by the interfaces between the binaries.

That would be great.  Then I could drop the gc_proxy stuff as well.

>>> So how about we rename windows._dll to windows.dll, and windows._thread to something else (dllthread? threadsupp?), then add the standardDllMain to windows.dll.
>> I'd like to hear Rainer's opinion on this --  I'd go along with
>> anything he says.
> 
> Adding standardDllMain() sounds good to me. I agree with windows.dll, too.
> 
> I'm not so sure about windows._thread. OSX has an osx.mach.thread_act, so we might want to have a similar naming for windows, but I have no idea what "act" stands for here.
> 
> Looking through the code, it mostly deals with the thread environment block, so windows.teb might be ok, but not really obvious.
> 
> dllthread: the code has nothing to do with DLLs explicitely, so it would not fit.
> threadsupp: maybe better: threadaux or threadhelp. The latter would at least match the naming of the dbghelp module.
> 
> Though not perfect, threadaux or threadhelp are my favorites.

Alrighty.