... 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