vicente.botet wrote:
Does it mean that the application is unable to know when things go wrong? Yes. Although extremely useful, logging is an auxiliary feature of the application, so it must not influence business logic. That is, users should not be bothered to wrap every log statement in a try/catch block.
IMO, it is up to the application to decide what to do with exceptional cases. The log library could catch its own exceptions, but not the user exceptions, and in any case let the user think that a log has been done when it is not the case.
Ok, I can make this behavior optional. Although I will most likely want to have all exceptions muted all the time.
Sources are not associated with sinks directly. A log record from any source may go to any one or several sinks. Which sinks will receive the record is entirely decided by filters.
So we can consider that sources + core + sinks form a single "log".
Sorry, I don't understand what you mean by "log". If it's a log file then it roughly corresponds to a single sink, not the whole set of objects you described.
So the BoostLog library consist of a single log with multiple sources and multiple sinks. The fact that we can declare as many loggers as we want staticly or as class member gives the illusion of multiple logs, but we have really just one core log.
I still don't understand what you mean by log. However, I don't see any illusion. You emit a log record through the logger, then it is processed according to the library set up. It may end up in one file, several or none, possibly in different form.
If an application needs to log different things in separated files (different modules, different people, 3pp) we need to create two sinks, a tag dispatcher, add the corresponding filters, create to channel_loggers, and share the tag dispatcher between the different modules, people and possibly 3pp. It seem to me that this could not scale. We really need to instantiate the core log.
There is no such thing as a "tag dispatcher" in the library. You are right, you need several sinks, each of them having a filter that will only pass records you want to see in the corresponding file (for example, records for a specific channel). That's it, the initialization stage ends here. In order to write logs you may create loggers as you need, these loggers may have different types and different attributes attached. If you want to emit a record to a particular channel, you can do so by attaching the channel name to the record as an attribute value. channel_logger does this automatically for you. Whether that channel is enabled or not, and what file it is written to, is a question of the library configuration, described earlier.
I don't think the explicit creation of a core log and the association of source and sinks to a core will complicate the library. The library could provide in addition a singleton log, so sources and sinks will be associated to this default core log.
I think, this will only confuse users. I don't see any reasonable use case where I would need to duplicate logging cores.
Yes but writing to different sources will check the filters on all the sinks. Doesn't this need to lock the mutex on the sink?
Only in read-access mode. Filters don't need serialized execution.
Looking forward to see this library in Boost! The idea of separate queues, along with lock-free queue from TBB, looks very appealing.
You can already take a look at https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Inter... or download it from the vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=interthreads.zip&directory=Concurrent%20Programming&
Thanks for the links, I'll take a look.
In addition this will solve the issue with log records that are weakly ordered in a multithreaded applications.
Do you plan at least to solve the weakly ordered issue before the review?
AFAIK, the review version of the library must be frozen according to Boost policy. But I'm surely not planning to drop the library, so this feature may appear in CVS before the review. However, I want to finish library tests before any other feature additions.