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.