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 08:12:51

On 03/14/2010 02:50 PM, Darryl Green wrote:
> On Sun, 2010-03-14 at 14:21 +0300, Andrey Semashev wrote:
>
>> 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?

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.

If my understanding is not correct, and the set of sinks is dynamically 
composed during filtering, then it doesn't differ from what Boost.Log 
currently does.

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

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. And since your setup is 
not static in the first place, all these caching dances are moot anyway.