On 2022-05-29 23:00, Ali Çehreli wrote:
On 5/29/22 13:53, Christian Köstlin wrote:
> According to
>
https://www.schveiguy.com/blog/2022/05/comparing-exceptions-and-errors-in-d/
> its bad to catch Errors ...
Correct in the sense that the program should not continue after catching
Error.
On 2022-05-29 23:08, Ali Çehreli wrote:
On 5/29/22 13:47, Christian Köstlin wrote:
> Our discussion with using TLS for the
> collectors proposed to not need any lock on the add method for
> collector, because its thread local and with that thread safe?
It would be great that way but then
On 5/29/22 13:47, Christian Köstlin wrote:
> Our discussion with using TLS for the
> collectors proposed to not need any lock on the add method for
> collector, because its thread local and with that thread safe?
It would be great that way but then the client changed the requirements
on us:
On 5/29/22 13:53, Christian Köstlin wrote:
> According to
>
https://www.schveiguy.com/blog/2022/05/comparing-exceptions-and-errors-in-d/
> its bad to catch Errors ...
Correct in the sense that the program should not continue after catching
Error.
> so dowork should catch only Exception?
On 2022-05-29 20:52, Ali Çehreli wrote:
On 5/27/22 06:55, Christian Köstlin wrote:
> I wonder how I can synchronize the "dumping" and the
> collection of the threads. Would be cool to have an efficient lockless
> implementation of appender ...
That turned out to be nontrivial.
The
On 2022-05-29 20:52, Ali Çehreli wrote:
On 5/27/22 06:55, Christian Köstlin wrote:
> I wonder how I can synchronize the "dumping" and the
> collection of the threads. Would be cool to have an efficient lockless
> implementation of appender ...
That turned out to be nontrivial.
The
On 5/27/22 06:55, Christian Köstlin wrote:
> I wonder how I can synchronize the "dumping" and the
> collection of the threads. Would be cool to have an efficient lockless
> implementation of appender ...
That turned out to be nontrivial.
The following is a draft I played with. Collector
On 2022-05-26 22:19, Ali Çehreli wrote:
On 5/26/22 12:54, Christian Köstlin wrote:
> 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.
I am not sure without testing but I am under the
On 5/26/22 12:54, Christian Köstlin wrote:
> 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.
I am not sure without testing but I am under the impression that mutexes
can be very slow
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
On 2022-05-26 01:05, frame wrote:
On Wednesday, 25 May 2022 at 21:35:07 UTC, Christian Köstlin wrote:
Is there also a way to get the "real"
threadid?
I'm using that functions inside threads:
core.sys.windows.winbase.GetCurrentThreadId on Windows
core.sys.posix.pthread.pthread_self on Unix
On Wednesday, 25 May 2022 at 21:35:07 UTC, Christian Köstlin
wrote:
Is there also a way to get the "real"
threadid?
I'm using that functions inside threads:
core.sys.windows.winbase.GetCurrentThreadId on Windows
core.sys.posix.pthread.pthread_self on Unix (implied pthreads are
used)
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
I experimented with application level tracing/profiling of d
applications similar to what is described in
https://dlang.org/blog/2020/03/13/tracing-d-applications/ as the
"writef-based approach". Only difference is, that I am emitting json
14 matches
Mail list logo
