[D-runtime] DLL initialization in Druntime

[Walter Bright]

Brad Roberts wrote:
> On Mon, 17 Jan 2011, Sean Kelly wrote:
>
>   
>> Darnit, you're right.  So the ideal scenario would be if the GC proxy 
>> could be set before the DLL load event was fired, which I think is 
>> impossible.  I also think it's important that a D DLL be usable by both 
>> a D and a non-D host app without a recompile, so we can't rely on 
>> gc_setProxy() ever being called (which is why I'm not terribly fond of 
>> gcstub to begin with).  This problem applies to any GC in the DLL 
>> though, so it still needs a solution.
>>
>> I can think of two solutions, though neither are terribly appealing.  
>> The first would be to require that D DLLs not create threads in their 
>> module ctors, and have gc_setProxy() call the module dtors, set the 
>> proxy, then re-construct the modules.  The second would be for 
>> gc_setProxy() to suspend all threads in the DLL, have the GC pass all of 
>> its allocated blocks as roots/ranges to the proxy, and then restart 
>> threads in the DLL.  The second seems far more robust, but imposes a 
>> rather large functionality requirement on the GC (a pseudo-collection).
>>
>> Thoughts?
>>     
>
> #3) require that d dll's call the appropriate registration function first.  
> Any user ctors must be 2-N.
>
>   

I agree with Brad. The only sure way to make it work is to have an 
initialization function, D_Initialize_Druntime(params...), that is 
required before accessing the functionality of the DLL. One of those 
params should be the gc proxy. This still works with a non-D caller.