[D-runtime] DLL initialization in Druntime

[Sean Kelly]

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