On Wednesday, 12 November 2014 at 12:39:24 UTC, Robert burner Schadek wrote:
> Only one thread can write to one Logger at a time, also known as synchronization. Anything else is properly wrong. But you can have as many Logger as you have memory.

One thing we can improve is to use thread-local stdlog singletons (that forward to global shared one by default) instead of using shared one as entry point. In server applications one would typically want to have logs buffered per thread or even sent to remote process / machine in parallel - while this can be done right now it would require applications to resort from using stdlog completely.

Better approach that comes to my mind is to have both thread-local and global configurable stdlog and have means to explicitly capture lock on global one from local proxies for optimized bulk logging.

IMO this defeats the design goal off having the default case very easy and just working. Therefore, I think thread local global Logger and how to make them interact is something that should be left to the advanced user.

On Wednesday, 12 November 2014 at 15:05:29 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 12 November 2014 at 12:39:24 UTC, Robert burner Schadek wrote:
>> Only one thread can write to one Logger at a time, also known as synchronization. Anything else is properly wrong. But you can have as many Logger as you have memory.
>
> Taking a lock when the logging call doesn't flush to disk sounds rather expensive.

If you log to a FileLogger it will flush. It is just a costly thing to do. There is no way get the work done but doing it.

Am Wed, 12 Nov 2014 17:56:06 +0000
schrieb "Dicebot" <public@dicebot.lv>:

> […] have means to explicitly capture lock on global one from local proxies for optimized bulk logging.

That's certainly something that occurred to me when talking
with Manu about logging. A locked bulk transfer could
be added, maybe replacing the single element transfer function
that exists already. Thread local loggers that accumulate logs
and pass them on to a global logger seem to be a well known
use case.

-- 
Marco

On Thursday, 13 November 2014 at 22:13:53 UTC, Marco Leise wrote:
> Am Wed, 12 Nov 2014 17:56:06 +0000
> schrieb "Dicebot" <public@dicebot.lv>:
>
>> […] have means to explicitly capture lock on global one from local proxies for optimized bulk logging.
>
> That's certainly something that occurred to me when talking
> with Manu about logging. A locked bulk transfer could
> be added, maybe replacing the single element transfer function
> that exists already. Thread local loggers that accumulate logs
> and pass them on to a global logger seem to be a well known
> use case.

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.

On Thursday, 13 November 2014 at 19:59:21 UTC, Robert burner Schadek wrote:
> IMO this defeats the design goal off having the default case very easy and just working. Therefore, I think thread local global Logger and how to make them interact is something that should be left to the advanced user.

How so? For casual end user hardly anything changes.

Right now there is a single shared stdlog singleton (configurable). I propose to rename it to something like stdlog_shared and provide thread-local stdlog singletons which by default will simply forward calls to stdlog_shared. That way default case will work exactly like it does now but it will make possible for advanced user to implement bulk loggers while still using same `stdlog` entry point (which is crucial in my opinion)

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?

On Thursday, 13 November 2014 at 19:59:21 UTC, Robert burner Schadek wrote:
> Therefore, I think thread local global Logger and how to make them interact is something that should be left to the advanced user.

Except that they can't actually get rid of all the overhead involved, as the locking is hard-coded into the Logger base-class. Granted, acquiring an uncontended lock isn't terribly expensive, but it's still a noticeable overhead if you are just logging to a thread-local buffer otherwise.

David

On Friday, 14 November 2014 at 21:43:53 UTC, David Nadlinger wrote:
>
> Except that they can't actually get rid of all the overhead involved, as the locking is hard-coded into the Logger base-class. Granted, acquiring an uncontended lock isn't terribly expensive, but it's still a noticeable overhead if you are just logging to a thread-local buffer otherwise.
>
> David

You can always roll your own non locking Logger, but the default should be thread-safe.

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, I take it you are familiar with the fact that locks aren't the only technique for achieving cross-thread synchronization.

David