Hello, a low level question about Windows internals and D
interacting with .NET at a low level.
I just made an experimental native .lib (static library) with
MS's C++ compiler, providing a C API for D to link to. The .lib
contains one module compiled with the /CLR option which provides
some functions manipulating .NET objects, and the C API is in
another module compiled to native code (no /CLR option),
containing the definitions of the functions to be exported to D,
which in turn call those in the CLR module via a mechanism
silently implemented by the MS compiler.
I then have successfully used both dmd and ldc2 to build a D test
program statically linked to this .lib calling the functions in
its API. It works fine in this toy singly threaded example. All
builds are 64-bit. I am using the versions of the compilers that
came with Visual D. As well as the C++ compiler that comes with
VS2022 (Community).
In the CLR module I have a static variable that can contain a
reference to a .NET object. I need that variable to be thread
local. I achieved this by prefixing its declaration with
[System::ThreadStaticAttribute]. But this is thread local for
.NET concurrency. How will this variable behave with a
multi-threaded D program (that calls those exported library
functions from more than one thread) and why?
I first had written the library code for a .dll (dynamic library)
and had the D test program be linked to its import library, so I
could make it work without the inevitable linkage issues. How
will the static variable behave in this situation with a
multi-threaded D program and why? --- the same as when statically
linked?
I'm looking for an actual technical explanation in both cases
please.
- Windows specific: MS C++ versus D th... NonNull via Digitalmars-d-learn
-
