Re: [boost] [log] Boost.Log formal review ongoing

Subject: Re: [boost] [log] Boost.Log formal review ongoing
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-14 07:21:11

On 03/14/2010 07:20 AM, Darryl Green wrote:
>
> Extending your lib by make our existing channel based log type into a
> logger feature and implementing open_record such that it applies the
> quick channel based filter first and returns a null record if the
> channel/logger is disabled would seem to be the best approach. It would
> also be desirable to use the set of sinks for which the channel filter
> passed to short circuit the core filtering by adding the set of sinks
> "attached" to the channel as an attribute of the message.
>
> Does that sound workable?

The trick with the quick filter in the logger feature is workable, and, 
in fact, should not be hard to implement, given that you already have 
the code that does filtering. But short circuiting the core is not 
doable without considerable changes in the core, log record and, 
probably, the logger. Also, this would make the loggers tied to the 
sinks, which may be just fine for your case, but not for Boost.Log in 
general.

On the other hand, if your logging setup is completely static, in the 
sense that if a log record from a log source passes filtering, it is 
safe to say it will always pass, and if it gets rejected, then all log 
records from this source will be rejected, then it might be enough for 
you to just cache the result of filtering in the log source. That way 
you'll be able to quickly drop records that would be dropped by actual 
filters anyway. In order to support dynamic configuration updates, those 
cached filtering results would have to be reset. It should be easy to do 
it by a signal (using Boost.Signals, for example).