Re: Calling D from C, C++, Python…
On Thursday, 10 September 2015 at 18:01:10 UTC, Russel Winder
wrote:
Is there an easy way of knowing when you do not have to
initialize the D runtime system to call D code from, in this
case, Python via a C adapter?
I naïvely transformed some C++ to D, without consideration of D
runtime systems, compiled it and it all worked. Which is good,
but…
Surely the reasonable choice is to always initialize the runtime
in a sensible location? What do you gain from not initializing
it, and is it really worth the effort?
core.runtime has Runtime.initialize and Runtime.terminate. In a
Windows DLL, it's sensible to use DllMain to call these.
core.sys.windows.dll.SimpleDllMain is a mixin template that makes
it easy:
version(Windows)
{
import core.sys.windows.dll;
mixin SimpleDllMain;
}
On Linux and other ELF-using platforms, initialization and
deinitialization functions could be placed in the .init and
.deinit special sections, but I don't know if druntime has any
convenient provisions for this. With GDC and LDC you can probably
use a pragma to put functions in these sections, but I don't know
if DMD has such a pragma.
I don't know what the equivalent is for Apple's Mach-O shared
libraries.
Re: Calling D from C, C++, Python…
On Sunday, 13 September 2015 at 10:10:32 UTC, Jakob Ovrum wrote:
On Thursday, 10 September 2015 at 18:01:10 UTC, Russel Winder
wrote:
Is there an easy way of knowing when you do not have to
initialize the D runtime system to call D code from, in this
case, Python via a C adapter?
I naïvely transformed some C++ to D, without consideration of
D runtime systems, compiled it and it all worked. Which is
good, but…
Surely the reasonable choice is to always initialize the
runtime in a sensible location? What do you gain from not
initializing it, and is it really worth the effort?
core.runtime has Runtime.initialize and Runtime.terminate. In a
Windows DLL, it's sensible to use DllMain to call these.
core.sys.windows.dll.SimpleDllMain is a mixin template that
makes it easy:
version(Windows)
{
import core.sys.windows.dll;
mixin SimpleDllMain;
}
On Linux and other ELF-using platforms, initialization and
deinitialization functions could be placed in the .init and
.deinit special sections, but I don't know if druntime has any
convenient provisions for this. With GDC and LDC you can
probably use a pragma to put functions in these sections, but I
don't know if DMD has such a pragma.
I don't know what the equivalent is for Apple's Mach-O shared
libraries.
Note that if the host program can call into the D shared library
from multiple threads, it's necessary to register those threads
with the runtime as well. The DllMain solution handles this
automatically, but for other systems additional handling is
necessary.
Re: Calling D from C, C++, Python…
On 2015-09-13 12:10, Jakob Ovrum wrote: On Linux and other ELF-using platforms, initialization and deinitialization functions could be placed in the .init and .deinit special sections, but I don't know if druntime has any convenient provisions for this. With GDC and LDC you can probably use a pragma to put functions in these sections, but I don't know if DMD has such a pragma. I don't know what the equivalent is for Apple's Mach-O shared libraries. It's supported in Mach-O as well, not sure about the section names though. -- /Jacob Carlborg
Re: Calling D from C, C++, Python…
On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg wrote: Well, if your D function doesn't use anything of the runtime I guess it's not necessary. Right. If you don't call into the threading system in the druntime, you should be ok. Keep in mind though that the GC uses the threads and the new expression, array literals, array append, and others use the GC. Runtime.initialize is also what calls static and module constructors... and might have responsibility for fixing up dynamic casting of class objects in a shared lib too, I'm not sure about that. But if you avoid the bulk of the runtime functions, indeed you can get away without initializing it. Just that null thread handle is likely to cause segfaults in places where you might not expect if you don't. It is best to initialize it. Lots of C libraries need an init an teardown call, so surely the Python interop provides some solution for it. idk what it would be though.
Re: Calling D from C, C++, Python…
On Saturday, 12 September 2015 at 18:20:37 UTC, Brad Roberts wrote: You can get away with it in some circumstances, but it's at your own risk. Yeah, I agree.
Re: Calling D from C, C++, Python…
On 9/12/15 9:20 AM, Adam D. Ruppe via Digitalmars-d-learn wrote: On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg wrote: Well, if your D function doesn't use anything of the runtime I guess it's not necessary. Right. If you don't call into the threading system in the druntime, you should be ok. Keep in mind though that the GC uses the threads and the new expression, array literals, array append, and others use the GC. Runtime.initialize is also what calls static and module constructors... and might have responsibility for fixing up dynamic casting of class objects in a shared lib too, I'm not sure about that. But if you avoid the bulk of the runtime functions, indeed you can get away without initializing it. Just that null thread handle is likely to cause segfaults in places where you might not expect if you don't. It is best to initialize it. Lots of C libraries need an init an teardown call, so surely the Python interop provides some solution for it. idk what it would be though. I think it's safest to say (and it belongs in the spec somewhere) that executing D code before initializing the runtime results in undefined behavior, or something along those lines. You can get away with it in some circumstances, but it's at your own risk.
Re: Calling D from C, C++, Python…
On Fri, 2015-09-11 at 21:50 +0200, Jacob Carlborg via Digitalmars-d -learn wrote: > On 2015-09-10 20:01, Russel Winder via Digitalmars-d-learn wrote: > > Is there an easy way of knowing when you do not have to initialize > > the > > D runtime system to call D code from, in this case, Python via a C > > adapter? > > You always need to initialize the D runtime, unless you have a D main > function. You can initialize the runtime as many times you like, > assuming you also deinitialize it the same number of times. I have a small D function (C linkage) compiled to a shared object that I am calling from Python via CFFI that works fine with no D runtime initialization. Thus I have experimental evidence "always" is not entirely the case! I really need to explore the boundaries of what point you have to actually initialize the D runtime… -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Calling D from C, C++, Python…
On 2015-09-12 10:56, Russel Winder via Digitalmars-d-learn wrote:
I have a small D function (C linkage) compiled to a shared object that
I am calling from Python via CFFI that works fine with no D runtime
initialization. Thus I have experimental evidence "always" is not
entirely the case! I really need to explore the boundaries of what
point you have to actually initialize the D runtime…
Well, if your D function doesn't use anything of the runtime I guess
it's not necessary. Example:
void foo ()
{
printf("foo\n");
}
--
/Jacob Carlborg
Re: Calling D from C, C++, Python…
On 2015-09-10 20:01, Russel Winder via Digitalmars-d-learn wrote: Is there an easy way of knowing when you do not have to initialize the D runtime system to call D code from, in this case, Python via a C adapter? You always need to initialize the D runtime, unless you have a D main function. You can initialize the runtime as many times you like, assuming you also deinitialize it the same number of times. -- /Jacob Carlborg
Calling D from C, C++, Python…
Is there an easy way of knowing when you do not have to initialize the D runtime system to call D code from, in this case, Python via a C adapter? I naïvely transformed some C++ to D, without consideration of D runtime systems, compiled it and it all worked. Which is good, but… -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
