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.
