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 and implementing open_record such that it applies the quick channel based filter first and returns a null record if the channel/logger is disabled would seem to be the best approach. It would also be desirable to use the set of sinks for which the channel filter passed to short circuit the core filtering by adding the set of sinks "attached" to the channel as an attribute of the message.
Does that sound workable?
The trick with the quick filter in the logger feature is workable, and, in fact, should not be hard to implement, given that you already have the code that does filtering. 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. 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. 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).