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.
