Voting: std.logger

[Kevin Lamonte via Digitalmars-d]

On Saturday, 30 August 2014 at 02:11:49 UTC, Dicebot wrote:

> "API must specify a strong stance on threading, whatever the
> form it takes"
>
> Does not seem to be addressed at all. At least I see no 
> mentions of it in core.d documentation and logger instance 
> itself is plain __gshared thing.

I'm not a "voter" as far as I know, but I suggest that Logger is 
formally documented to be not-thread-safe, and that it is the 
responsibility of subclasses to provide thread safety.  Actual 
Logger's can do so easily by overloading 
beginLogMsg/logMsgPart/finishLogMsg and not using a shared class 
variable between calls.  Loggers could also remain thread-local 
but overload writeLogMsg to dispatch the result to thread-safe 
I/O.  The latter is the path I have chosen currently for log4d 
(https://github.com/klamonte/log4d).  (That may change in the 
future if there is memory pressure from too many thread-local 
logger instances.)

> "We need to hammer out how this will work inside libraries.  If 
> my app is
> using multiple libraries I need to know I have full control of 
> how they
> log and where (), and if I write libraries I need to include 
> logging that
> will not affect performance or added dependencies.

This is a task for a fuller backend, not the std.logger frontend. 
  std.logger should be "mechanism", interfacing multiple libraries 
together requires "policy".

> "Logger should include a shared Logger, or include it in the 
> interface for
> outside libraries to handle the implementation.  There will be 
> libraries
> that thread internally and will need to support shared logging."
>
> Is not addressed.

stdlog is global and the default implementation is thread-safe by 
way of FileLogger mutex-locking its writes.  It should either be 
documented that stdlog is always global and it is up to 
subclasses or logging backends to make stdlog thread-safe, or 
Logger should be made thread-safe by default by eliminating it's 
header and msgAppender fields.  I'm not sure either way which is 
better.

I don't like the idea that libraries A, B, and C will just 
blindly use stdlog and hope for the best.  If they are "logging" 
(and not "tracing", for which I hope D evolves a @trace 
attribute) then they should be logging by category/name, which is 
a job for something like log4d.  But Logger's don't have names.

Perhaps the better solution would be a convention for libraries 
to always use a "static Logger Logger.getLogger(string category)" 
function, for which the default simply ignores category and 
returns stdlog.  "Logger.setGetLoggerFunction(...)" could be 
provided for backends to change this behavior on application 
startup, assuming they can guarantee that they can call this 
function before various libraries have gotten references to 
stdlog.