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
