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
