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.