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

[Sean Kelly]

BCS wrote:
> Sean Kelly wrote:
>> 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.
> 
> You would need a special Phobos to do it.

Well, that's basically what Ares is :-)  Though it would be easy enough 
for Walter to add to Phobos if he thought it was a good idea.

 > For that matter, you would
> also want a hacked startup section to automatically hook into the gc.so, 
> same for the so's themselves. (They have some start up code don't they?)

cr_init would initialize the GC, run module ctors, and any other special 
things that need doing.  cr_term would shutdown the GC, run module 
dtors, etc.  These functions would simply be called in internal/dmain2 
instead of the code being inline.

> I guess what you'd have is a complete duplication of the D runtime. One 
> set (what is there now) for static linking and one set (with the above 
> hacks, and more I assume) for dynamic linking.

Dynamic linking is a pain, which is why I've avoided the issue thus far. 
  DDL is another option that I think is far preferable in instances 
where it can be used.  I'll admit I'm not at all keen on trying to turn 
the compiler runtime code into a DLL, what will all the exports likely 
required and such.


Sean