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/lcsjtxorbbagmbvbl...@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.
