Re: [Boost-users] yet another logging library

From: Mojmir Svoboda (mojmir.svoboda_at_[hidden])
Date: 2008-06-16 10:29:04

> ...
> be connected to a "sink" specific for that thread.

> This approach was chosen after making some observations:
> 1) Synchronization has a performance penalty.
and not a trivial one :/

> 2) Synchronization might affect the behaviour of the program when
> increasing the amount of logged data, potentially leading to heisenbugs.
heisenbugs ;))
> 3) Sometimes you actually never need to merge the streams of events.
> 4) Since the logged data is used for "external" diagnostics only, the
> library should allow the application generating the logs to do as little
> as necessary before storing them away. Storing primary measurement data,
> in a sense.

i agree there. i'd like to minimize the interference of the debugging
mode from the normal flow as much as possible.

maybe with exception of the runtime filtering facilities. i thought
about it and these runtime values are read only most of the time.
it depends - use either spinlocks if they are likely to be modified
at runtime or marked simply as volatile and restrict write only
to initialization phase.

> The idea was to separate the generation of a log event from the
> synchronization, transformation and storage of log events.

exactly.

> In this way, the cost of synchronization of multiple log streams is
> moved to a later stage. It can either be done in a designated "merger"
> thread inside the application, reading from lock-free queues connected
> to the "thread loggers", or each stream can be sent to a different file
> or network socket and merged off-line by a diagnostics tool (if needed).

aaaaah, the agony of re-discovering the already discovered ;-)
don't you have sources available?

best regards,
mojmir