Hi to all!
I tried to discuss this theme on IRC, but the problem is that my time is GMT+6, so there is a small amount of real time interaction. And I decided to migrate it to forum.
Here is the small info about the project. There is a big C++ application. And there is a big wish to rewrite it using Nim. But it's a big application and we need a lot of time to do it. So I created a library where I want to put a new or rewritten functionality written in Nim and then use it in main C++ application.
The problem is that the application is multithreaded and threads created from C++ code, so there is no Nim's thread bootstrapping i.e. threadProcWrapper from threads.nim.
There is the setupForeignThreadGc function, that must be used in not Nim's threads. But there was a problem with it (https://github.com/nim-lang/Nim/pull/3786). The problem is that GC uses thread local storage. And if we use --tlsEmulation:on, we can't use setupForeignThreadGc.
Ok, let's use --tlsEmulation:off and all must be ok. But no. Windows and gcc strikes back. See https://github.com/nim-lang/Nim/issues/3889. Of course, this is just a synthetic test, but the stacktrace is almost the same as I saw in the real application.
TLS works in such way, that there must be no conflicts between the libraries, but it's only in dreams. In real life, I want to use --tlsEmulation:on to have no conflicts between TLS used by Nim and by C++.
So, what do you think if I make the public API from the thread's wrapper from threads.nim? Is this a solution for the --tlsEmulation:on problem, or maybe I can do it a better way?
And what about the issue 3889? I think that it's a big problem and it's not clear what it may cause in the real applications written for windows and compiled with gcc.
Small addition. Tried boehm GC on this example:
proc test() =
discard
var t1, t2: Thread[void]
createThread(t1, test)
createThread(t2, test)
joinThreads(t1, t2)
And it produces abnormal program termination with and without TLS emulation. So, changing GC is not a variant :-(