Criteria for 1.0 (was: Re: If D becomes a failure, what's the key reason, do you think?)

[Sean Kelly]

BCS wrote:
> Kirk McDonald wrote:
>> Walter Bright wrote:
>>
>>> Kirk McDonald wrote:
>>>
>>>> Here's something that has been annoying me, and this week-old thread 
>>>> is as good a place as any to bring it up: Shared library support on 
>>>> Linux. I could not take D seriously if it did a "1.0" release 
>>>> without this. I do hate to cram more on your plate, Walter, but I 
>>>> consider this a more serious issue than even this import thing that 
>>>> has gripped the newsgroup for the past week.
>>>
>>>
>>>
>>> I know about the shared library issue on Linux. And to tell the 
>>> truth, I've been procrastinating on it. The big job, -fPIC, is done. 
>>> I don't know how much beyond that needs to be done.
>>>
>>> Will the shared libraries work with GDC?
>>
>>
>> Ha! Well, at least this simple case does:
>>
> [proof]
>>
>> Sweet. However, I am a little concerned. When making DLLs on Windows, 
>> there is some boilerplate code needed to initialize and shut down the 
>> GC and do some other routine things. Is something like that needed here?
>>
> 
> 
> Doesn't said boilerplate consist of linking the GC of the calling 
> program in to the GC of the called so? why not do it the other way 
> around? place the GC in its own so and have everything else link in to 
> it? Not too clean for small projects but once you are using so's anyway 
> it would be cleaner than putting gc hookup code all over the place.

The issue is somewhat messy.  If Phobos is statically linked and the 
user DLL is loaded by a D app then there would be two GCs and two thread 
lists that need to cooperate.  It would be far preferable to put Phobos 
in a DLL of its own so only a single copy of this code is in use.  But 
now assume the DLL is loaded by a C app.  The user DLL would have to 
load/attach to the Phobos DLL.  I think the "cr_init" and "cr_term" 
functions I mentioned in my other post might have to be reentrant for 
everything to work properly?  I'll admit to having given the DLL issue 
basically no thought so far.


Sean