On Wednesday, 3 September 2014 at 03:05:42 UTC, Kevin Lamonte
wrote:
On Tuesday, 2 September 2014 at 14:53:17 UTC, Dicebot wrote:
This is exactly what I call theoretical speculations. Please
provide specific list like this:
1) some method signature needs to be changed
I propose the following API changes (+ changes on default
implementation):
protected LogEntry beginLogMsg(string file, int line,
string funcName,
string prettyFuncName, string moduleName, LogLevel
logLevel,
Tid threadId, SysTime timestamp, Logger logger)
@trusted
{
static if (isLoggingActive())
{
return LogEntry(file, line, funcName,
prettyFuncName,
moduleName, logLevel, threadId, timestamp,
null, logger);
}
}
/** Logs a part of the log message. */
protected void logMsgPart(MsgRange msgAppender,
const(char)[] msg)
{
static if (isLoggingActive())
{
msgAppender.put(msg);
}
}
/** Signals that the message has been written and no more
calls to
$(D logMsgPart) follow. */
protected void finishLogMsg(ref LogEntry entry, MsgRange
msgAppender)
{
static if (isLoggingActive())
{
entry.msg = msgAppender.data;
this.writeLogMsg(entry);
}
}
...with the corresponding changes to logImpl/logImplf to create
msgAppender as a local function variable, and the elimination
of header and msgAppender as Logger class variables.
The benefit to this change is that Logger (including stdlog)
becomes thread-safe, as well as any subclass of Logger that
only implements writeLogMsg().
The only problem with that change is that it will always require
a buffer. FileLogger currently doesn't require a buffer and is
already thread-safe.
stdlog will not be thread-safe by default by this change only
syncing the writeLogMsg function will.
