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.

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.

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?

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).

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 :)

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.

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.