std.experimental.logger formal review round 3

[Marco Leise via Digitalmars-d]

Am Sat, 15 Nov 2014 02:11:34 +0000
schrieb "Robert burner Schadek" <rburners at gmail.com>:

> On Friday, 14 November 2014 at 23:40:21 UTC, David Nadlinger 
> wrote:
> > On Friday, 14 November 2014 at 22:18:41 UTC, Robert burner 
> > Schadek wrote:
> >> Yes, but this way allows to add structured logging in an easy 
> >> way.
> >
> > What.
> 
> The actual log call is split into multiple parts so that the user 
> can overload logMsgPart and add, for instance, structured 
> logging. In order to not have races with the default impl locking 
> was added.

Somehow I feel like I should be in the firing line here, hehe.
Yes, this is approach to thread-safety isn't the most efficient
imaginable. But it can guarantee thread-safety no matter how
little or much you know about the default logger internals or
what you plan to do with it. The lock also ensures that
public properties like logLevel cannot change while a logger
is working, which could result in log messages being dropped
that should have passed and - as Robert mentioned - ensures
that the 3 structural logging methods are called in order with
no other thread intervening.
I believe it will hit a sweet spot between safe extensibility
and performance.
Benchmarking... Hmm, you can take an uncontested lock
~14.000.000 times per second on Linux @ 2 Ghz with D's
synchronized(...) {} statement and you can append "The quick
brown fox jumps over the lazy dog." ~22.400.000 to an
Appender!(string[]). I begin to understand what you mean by
"noticeable". Somehow I hope that people don't log that much
or that the loggers themselves are sufficiently complex that
they take their time to process each message. But for a
thread-local logger that just appends to a list, it is quite
a bit of unnecessary overhead.

-- 
Marco