LDC_global_crt_ctor for threads

Guillaume Piolat firstname.lastname at gmail.com
Wed Apr 8 11:30:55 UTC 2020


On Friday, 3 April 2020 at 19:16:04 UTC, Marcel wrote:
> On Friday, 3 April 2020 at 00:37:39 UTC, kinke wrote:
>> On Thursday, 2 April 2020 at 22:16:45 UTC, Marcel wrote:
>>> Oh, I didn't explain my situation properly: I'm writing a 
>>> memory allocation library and there's some thread local state 
>>> that I must take care of when the thread exits. Now, I can 
>>> always do as you said and ask the user to place calls to 
>>> certain functions at thread main, but I'd really prefer if 
>>> that was done automatically.
>>
>> You'll need some sort of runtime support for automation, so if 
>> you don't use druntime because of -betterC, you'll need to 
>> look (and ask) elsewhere. C doesn't have such a thing AFAIK; 
>> the C++ runtime may have something like __cxa_thread_atexit 
>> (e.g., used by clang for a thread_local global with dtor when 
>> targeting glibc).
>
> I see... A shame but it's understandable.
> Thank you anyway :)

Hello,

In dplug:core's thread pool (not -betterC but without runtime or 
static destructor) we pass an "id" from 0 t N-1 with N being the 
number of threads.

This is to allow thread-local access:
https://github.com/AuburnSounds/Dplug/blob/master/core/dplug/core/thread.d#L383

Thread-local data is created or destroyed out of band by the 
caller who knows the number of threads in the pool. For your 
case, it would be after threads are join()'ed.




More information about the digitalmars-d-ldc mailing list