Initializing D runtime and executing module and TLS ctors for D libraries

[Ali Çehreli]

Thank you very much for your answers. I think I've been on the right 
track and the following bug that I've mentioned has been messing up by 
hitting me randomly:

   https://issues.dlang.org/show_bug.cgi?id=11736

On 1/23/21 5:18 PM, IGotD- wrote:

 > During rt_init in the main thread, thread_attachThis is performed what I
 > have seen.

That explains why everything just works on most cases.

 > Actual ctor code that runs for each TLS thread is language specific and
 > not part of the ELF standard therefore no such TLS ctor code are being
 > run in the lower level API. The initialization (only copy and zeroing)
 > of TLS data is being done when each thread starts.

That must be the case for threads started by D runtime, right? It sounds 
like I must call rt_moduleTlsCtor explicitly for foreign threads. It's 
still not clear to me which modules' TLS variables are initialized 
(copied over). Only this module's or all modules that are in the 
program? I don't know whether it's possible to initialize one module; 
rt_moduleTlsCtor does not take any parameter.

 > This can even be done
 > in a lazy manner when the first TLS variable is being accessed.

I hope that's the case.

 > I have to make a generic API and then a D
 > API on top of that.

Did you mean a generic API, which makes calls to D? That's how I have 
it: an extern(C) API function calling proper D code.

 > In practice this means there is a trampoline
 > function involved where and thread_attachThis and thread_detachThis is
 > being called. Also this is where I call TLS ctors/dtors.

That's what I will be doing.

 > It is an effect
 > that delegates is language specific and it falls natural that way. Avoid
 > extern(C) calls directly into D code.

I hope I am misunderstanding you there. All I have are extern(C) 
function on the library API.

 > In practice you can do this for any thread even if there are several
 > delegates during the thread lifetime. You can simply have a TLS bool
 > variable telling if the thread_attachThis and rt_moduleTlsCtor have
 > already been run.

I've already experimented with it but it didn't work likely because of 
the bug mentioned above.

 > In general the main thread that goes into main must also be the last one
 > returning the entire line of functions that was called during entry of
 > the process.

Main entry belongs to another language, so I have to document that this 
library can only work in such "well behaved" cases.

 > What will happen is that you possibly do a
 > thread_detachThis twice.

Sounds like I can track that with a bool variable as well, no?

 > Short answer is just park the main thread while the bulk is being done
 > by other threads. Unfortunately that's how many libraries work today.

Agreed. That's for me to specify in the library documentation.

I should revive my old PR and see whether it is needed at all:

   https://github.com/dlang/druntime/pull/1989

I am surprised how much I had learned at that time and how much I've 
already forgotten. :/ For example, my PR involves thread_setThis, which 
seems to be history now:

 
https://docarchives.dlang.io/v2.068.0/phobos/core_thread.html#.thread_setThis

And thread_detachThis seems to be missing now:

   https://dlang.org/phobos/core_thread.html

   https://dlang.org/phobos/core_thread_osthread.html

Documentation issue or is it not needed anymore?

Ali