Boost Users :
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.
> 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.
> 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?
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net