## digitalmars.D.learn - Calling D from C, C++, =?UTF-8?Q?Python=E2=80=A6?=

Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```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

I na=C3=AFvely transformed some C++ to D, without consideration of D runtim=
e
systems, compiled it and it all worked. Which is good, but=E2=80=A6

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
```
Sep 10 2015
Jacob Carlborg <doob me.com> writes:
```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

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
```
Sep 11 2015
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```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

=20
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,=20
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=E2=80=A6

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
```
Sep 12 2015
Jacob Carlborg <doob me.com> writes:
```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
```
Sep 12 2015
"Adam D. Ruppe" <destructionator gmail.com> writes:
```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

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.
```
Sep 12 2015
Brad Roberts via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```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

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.
```
Sep 12 2015
"Adam D. Ruppe" <destructionator gmail.com> writes:
```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

Yeah, I agree.
```
Sep 12 2015
Jakob Ovrum <jakobovrum gmail.com> writes:
```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.
```
Sep 13 2015
Jakob Ovrum <jakobovrum gmail.com> writes:
```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
with the runtime as well. The DllMain solution handles this
automatically, but for other systems additional handling is
necessary.
```
Sep 13 2015
Jacob Carlborg <doob me.com> writes:
```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
```
Sep 13 2015