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

[Kirk McDonald]

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.
> 
> 
> Sean

I just did some testing, and this is exactly right. I modified the old 
myso2.d to create a class and instantiate it:

[myso2.d]
module myso;

import std.stdio;

class A {
     ~this() { writefln("A.~this()"); }
     void foo() { writefln("A.foo()"); }
}

export extern(C)
void mysoprint() {
     A a = new A;
     a.foo();
}

When loaded by a D module, it works just fine. However, the following 
promptly causes Python to segfault when imported:

[testpy.d]
import python;
import std.stdio;

PyMethodDef testpy_methods[] = [
     { null, null, 0, null }
];

class A {
     ~this() { writefln("A.~this()"); }
     void foo() { writefln("A.foo()"); }
}

extern(C)
export void inittestpy() {
     Py_InitModule("testpy", testpy_methods);
     A a = new A;
     a.foo();
}

 >>> import testpy
Segmentation fault
$

This, however, runs fine:

[testpy2.d]
import python;
import std.stdio;

PyMethodDef testpy_methods[] = [
     { null, null, 0, null }
];

extern(C)
export void inittestpy() {
     Py_InitModule("testpy", testpy_methods);
     writefln("Hello, world!");
}

 >>> import testpy2
Hello, world!
 >>>

It seems clear to me that the GC is causing the trouble.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki