Tracing/Profiling D Applications

[Christian Köstlin]

On 2022-05-25 23:56, Ali Çehreli wrote:
> On 5/25/22 14:35, Christian Köstlin wrote:
> 
>  > 1. I went for a singleton for storing tracing/logging information that
>  > needs to be initialized manually. Is __gshared the right way to do that?
> 
> I think this is where thread-local storage comes in handy. As the D 
> runtime does for dmd's -profile command line switch, you can have a 
> module-level Appender, which collects data for that thread without 
> worrying about race conditions.
Nice idea. Similar to the fast singleton here: 
https://p0nce.github.io/d-idioms/#Leveraging-TLS-for-a-fast-thread-safe-singleton

Not sure if this will work for me though, as I want to be able to dump 
tracings even while the program is still running. Then I would have to 
collect the tls data of all still running threads.

>  > to unlock the mutex?
> 
> You need the mutex only when each thread is exiting to combine their 
> results. Each static ~this() could grab the mutex and add its result to 
> the one global Appender. And that "global" Appender would be 'shared' or 
> __gshared; doesn't matter.
Thanks for the explanation. From my understanding __gshared does not put 
the shared type attribute the the profiler. If I use shared I would also 
have to make all methods I call on the shared profiler shared and also 
would have to have a shared appender (or cast shared away)?

Kind regards,
Christian