• kookman (10/10) Aug 17 2016 I was interested low(er) cost logging and stumbled across a
• Robert burner Schadek (8/18) Aug 17 2016 stdThreadLocalLog's log functions are synchronized because they

kookman <thekookman gmail.com> writes:

I was interested low(er) cost logging and stumbled across a 
proposal by Max Klimov from about 16 months ago to add an 
AsyncLogger to std.experimental.logger (ref 
http://forum.dlang.org/thread/lcsjtxorbbagmbvbllns forum.dlang.org). The
resulting PR 3194 has been dormant for some time. I was going to resuscitate
it, but I wanted to change the approach - rather than make AsyncLogger a
generic wrapper for another logger type, I wanted to make a specialist logger
that was designed to always be the stdThreadLocalLogger. It would be a stub
that merely sends a LogEntry (as a message) to the stdSharedLogger (which would
be any logger type).

When taking a closer look at std.experimental.logger I realized 
that with the current design, becauseThreadLocalLog is just 
another Logger, it is paying all the cost of  sychronization, 
even though it is thread local.

Am I interpreting the purpose of stdThreadLocalLogger differently 
to how it was intended?

Robert burner Schadek <rburners gmail.com> writes:

On Wednesday, 17 August 2016 at 07:48:02 UTC, kookman wrote:
 I was interested low(er) cost logging and stumbled across a 
 proposal by Max Klimov from about 16 months ago to add an 
 AsyncLogger to std.experimental.logger (ref 
 http://forum.dlang.org/thread/lcsjtxorbbagmbvbllns forum.dlang.org). The
resulting PR 3194 has been dormant for some time. I was going to resuscitate
it, but I wanted to change the approach - rather than make AsyncLogger a
generic wrapper for another logger type, I wanted to make a specialist logger
that was designed to always be the stdThreadLocalLogger. It would be a stub
that merely sends a LogEntry (as a message) to the stdSharedLogger (which would
be any logger type).

 When taking a closer look at std.experimental.logger I realized 
 that with the current design, becauseThreadLocalLog is just 
 another Logger, it is paying all the cost of  sychronization, 
 even though it is thread local.

 Am I interpreting the purpose of stdThreadLocalLogger 
 differently to how it was intended?

stdThreadLocalLog's log functions are synchronized because they 
read global and instance global data structures. And I didn't 
want make in possible to introduce the possibilities for race 
conditions. Thats why the logXXX member functions of Logger are 
synchronized.

You can still build up a LogEntry and send it, it just has to be 
in synchronized block.