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

Subject: Re: [boost] [log] Boost.Log formal review ongoing
From: Darryl Green (darryl.green_at_[hidden])
Date: 2010-03-14 07:50:15

On Sun, 2010-03-14 at 14:21 +0300, Andrey Semashev wrote:
> 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...
> 
> The trick with the quick filter in the logger feature is workable, 

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

I'm not quite following what coupling you are concerned about. Our
existing logger has a shared ptr to a (maintained by the filtering
logic) container of shared ptrs to sinks which seems harmless enough?
Even if the attribute value isn't literally a container of pointers to
sinks, it would surely be possible to have an attribute value
identifying (with help from a sink front end filter that checked the
attribute) which sinks the logger fast filter had selected?

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

True. Except that it isn't completely static...

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

Conceptually yes, that would work.