November 14, 2014
On 11/14/14 4:22 PM, Dicebot wrote:
> On Thursday, 13 November 2014 at 22:19:55 UTC, Robert burner
> Schadek wrote:
>> One bad thing about that is that the global log is no longer sorted by
>> time if you write to any file. That would make using the log much more
>> difficult IMO.
>
> We do have timestamp as part of recorded log data, don't we?

I'm not following this thread, but please please please -- output log data in chronological order. If you have to have another object that does it, fine. But I don't want to have to rely on sorting utilities to properly read a log file.

-Steve
November 14, 2014
On Friday, 14 November 2014 at 22:02:30 UTC, Steven Schveighoffer wrote:
> On 11/14/14 4:22 PM, Dicebot wrote:
>> On Thursday, 13 November 2014 at 22:19:55 UTC, Robert burner
>> Schadek wrote:
>>> One bad thing about that is that the global log is no longer sorted by
>>> time if you write to any file. That would make using the log much more
>>> difficult IMO.
>>
>> We do have timestamp as part of recorded log data, don't we?
>
> I'm not following this thread, but please please please -- output log data in chronological order. If you have to have another object that does it, fine. But I don't want to have to rely on sorting utilities to properly read a log file.
>
> -Steve

I have meant that shared logger can do sorting based on timestamp upon receiving chunks for thread-local ones before sending it forward - it would require defining strict syncing period between loggers though.
November 14, 2014
On Friday, 14 November 2014 at 21:49:09 UTC, David Nadlinger wrote:
> On Friday, 14 November 2014 at 21:46:00 UTC, Robert burner Schadek wrote:
>> You can always roll your own non locking Logger, but the default should be thread-safe.
>
> You can't, since you need to inherit from Logger, which already does the locking for you in a way that's not overridable. Also,

My bad, I mixed something up.

> I take it you are familiar with the fact that locks aren't the only technique for achieving cross-thread synchronization.

Yes, but this way allows to add structured logging in an easy way.

November 14, 2014
I will test something this weekend regarding the additional indirection.
November 14, 2014
On Friday, 14 November 2014 at 22:02:30 UTC, Steven Schveighoffer wrote:
> I'm not following this thread, but please please please -- output log data in chronological order.

I'm not sure if you can define a strict chronological order between threads since logging happens "after the fact" which may be truly parallel (in a race). If you want strict chronological order between threads you can use an atomic counter for a serial id…

For a web server this is usually not that interesting. You are interested in chronological order on the first dispatch and then on the request (the fiber id?)...

When you are doing buffering with one producer and one consumer on a circular buffer you usually don't need locking or atomics since single read/writes are atomic on x86 AFAIK. And with double/triple buffering you only need an occasional CAS.

I can think of at least of 3-4 ways of getting a performant multithreaded logger with almost no locking.
November 14, 2014
On Friday, 14 November 2014 at 22:20:17 UTC, Robert burner Schadek wrote:
> I will test something this weekend regarding the additional indirection.

Thanks! I may try hacking some sample implementation too but pessimistic about ETA
November 14, 2014
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.
November 15, 2014
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.
November 17, 2014
On Wednesday, 29 October 2014 at 23:16:28 UTC, Robert burner Schadek wrote:
> The reason for the crowbar sometimes you need to disable all calls to the Logger or any calls to a specific LogLevel in the compile unit, even for Logger not wrapped in LoggerCT.

Only that there is no clean boarder between modules because of inlining and templates.
November 17, 2014
On Wednesday, 29 October 2014 at 23:11:44 UTC, Robert burner Schadek wrote:
> That can actually be added to the current state of std.logger without breaking any api.

Just a few additions to handle LoggerCT (which needs a better name).

> Anyway IMO your approach presented here and my approach can go hand in hang. Yours should be propagated as the idiomatic way and if you really need the crowbar, which you need sometimes, use StdLoggerDisableXXXXX.

Yes, that would work for me.
It's just important to control logging on a per library basis.