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-17 10:32:17

On Sun, 2010-03-14 at 15:12 +0300, Andrey Semashev wrote:
> On 03/14/2010 02:50 PM, Darryl Green wrote:
> > On Sun, 2010-03-14 at 14:21 +0300, Andrey Semashev wrote:
> >
> My understanding was that your loggers had a set of pointers to sinks, 
> which does not change, unless the configuration is updated (which was 
> the reason of higher performance). This is the coupling I was talking 
> about - a logger is bound to the fixed set of sinks, and in no way it 
> can emit a record that would pass to a sink outside of this set.

Right. Although the use of "fixed" is (as you do say when you say it can
be updated) overstating it a bit. I'm not really seeing why this is a
problem for boost log - I've pretty much convinced myself I could graft
the scheme I need in front of boost log without breaking anything. 

> > 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?
> 
> I think, you've missed an important thought before this, which makes me 
> hard to understand what you meant here.

If rather than having the logger use a set of pointers to route to sinks
directly, it delivered its set of "pointers" as an attribute that sink
filters could check for a match, then there would be no coupling issue.
The "pointers" could, be, for example, a sequence of assumed sink names
- but the filtering could chose to relate names to sinks in any way.

> Again, if your setup is static, in the sense I described earlier, you 
> can cache the set of sinks which consumed the particular record (since 
> you can always be sure that the set will always be the same). However, 
> that won't speed things up, since even if you pass that cached 
> information to the filter with the next record, it will have to find its 
> sink in it, hence you will still have a lookup.

Yes - that is similar filtering/performance wise to what I described
above.

>  And since your setup is 
> not static in the first place, all these caching dances are moot anyway.

It is as static as filters are. Which is very static compared to log
record generation rate, so caching is an excellent strategy.
 
Unfortunately I've also pretty much convinced myself that while the idea
of attributes is powerful I don't much care for the way they are
provided by boost log, so I won't be pursuing the sort of integration
that we have been discussing. See my review for details.