www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC_global_crt_ctor for threads

reply Marcel <marcelpi97 gmail.com> writes:
Hello!
Is there a way to call a cleanup function when a thread 
terminates, like with LDC_global_crt_ctor? I can't use module 
ctor/dtors since I'm using BetterC.
Apr 02
parent reply Calvin P <changlon gmail.com> writes:
On Thursday, 2 April 2020 at 15:28:43 UTC, Marcel wrote:
 Hello!
 Is there a way to call a cleanup function when a thread 
 terminates, like with LDC_global_crt_ctor? I can't use module 
 ctor/dtors since I'm using BetterC.
a simple scope(exit) do_clear(); in the thread entry function will do the work. if you need put them in multi files, you need constructor a global list or array, init from LDC_global_crt_ctor. then call from thread entry function.
Apr 02
parent reply Marcel <marcelpi97 gmail.com> writes:
On Thursday, 2 April 2020 at 17:07:58 UTC, Calvin P wrote:
 On Thursday, 2 April 2020 at 15:28:43 UTC, Marcel wrote:
 Hello!
 Is there a way to call a cleanup function when a thread 
 terminates, like with LDC_global_crt_ctor? I can't use module 
 ctor/dtors since I'm using BetterC.
a simple scope(exit) do_clear(); in the thread entry function will do the work. if you need put them in multi files, you need constructor a global list or array, init from LDC_global_crt_ctor. then call from thread entry function.
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. Also, using global lists for thread state management will likely lower performance for applications that rapidly create and delete threads... Is there no other way?
Apr 02
parent reply kinke <noone nowhere.com> writes:
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).
Apr 02
parent reply Marcel <marcelpi97 gmail.com> writes:
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 :)
Apr 03
next sibling parent kinke <noone nowhere.com> writes:
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 :)
You could add the module dtor for non-`version(D_BetterC)` though and add a non-betterC configuration to your library. Normal D stuff would link against that config and work out of the box; -betterC guys have to put up with the restrictions imposed by a missing druntime.
Apr 03
prev sibling parent Guillaume Piolat <firstname.lastname gmail.com> writes:
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.
Apr 08