Re: [boost] [log] v2 Initialisation, default sink behaviour and filtering documentation

Subject: Re: [boost] [log] v2 Initialisation, default sink behaviour and filtering documentation
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-02-08 03:17:36

On Friday 08 February 2013 07:53:32 Mats Taraldsvik wrote:
> > 
> > I take it that you are initializing the library while initializing a
> > global logger the first time, is that right? If so, then you probably
> > should move all library initialization code (including addition of sinks
> > and attributes to the core) to an external function and protect it with
> > call_once, once blocks or another similar mechanism. Then you will be
> > able to invoke it multiple times for different global loggers without
> > reinitializing the core.
> 
> Unfortunately, no. I'm implementing a new module called by a legacy
> interface, and don't know the number of instances of that interface present
> at a given time (probably, it will be limited to one, but in my test code
> at least, multiple instances exist). Each interface therefore has its own
> logger object, and the initialization of this object, along with the
> initialization of backends/sinks/core, happens at construction of the
> interface object.
> 
> Currently I'm calling remove_all_sinks, and this works well. Another
> approach, that you suggest, would be a static once_flag member for the
> interface, and call_once for the backends/sink/core initialization. The
> latter introduces some complexity, and the former is not ideal. I think
> I'll try to avoid the complexity if the remove_all_sinks approach does not
> cause any issues..

If you use remove_all_sinks and reinitialize sinks etc. while the other 
instance of your module is active, it is possible that you lose a few records 
in the output (they will be fed to the default sink). I think, this was the 
original issue you mentioned, right? The call_once approach solves this 
problem.

> > The code sample in the sinks description is not related to trivial
> > logging, and actually the filter itself is not important in that example.
> > For clarity, if the filter extracts an int, like in that example, it
> > won't work with other types, so the example assumes that the logger is
> > also using int for severity levels. You can see it in the complete code
> > of the example.
> 
> If you could include exactly that paragraph in the docs, when you move from
> trivial::severity_level to int, that would make things clearer :)

Ok, I'll see if I can clarify the docs.

> As a side note, I'm extremely satisfied with the library. Thanks for
> developing it! :)

Thank you for the kind words. :)