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.