[D-runtime] DLL initialization in Druntime

[Walter Bright]

Sean Kelly wrote:
> On Jan 17, 2011, at 5:07 PM, Walter Bright wrote:
>   
>> 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.
>>     
>
> The unfortunate part is that this isn't necessary when using Runtime.loadLibrary(), since that will do the right thing.

It can't do the right thing, as there's no way to pass a parameter to 
DLL_PROCESS_ATTACH.

>   It would only be necessary for a non-D hosting app.  I guess if it has an "already ran" flag in it then the library writer could have his init_my_lib() routine call it instead.  *sigh*  No automatic alternatives, huh?
>
>