----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, February 12, 2009 6:55 PM Subject: Re: [boost] [log] Review-ready version in the Vault
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.
I understand you position, but there are situations that need the oposit.
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.
Well, the library is names Boost.Log isnt' it. When I talk in your library context of log I mean sources + core + sinks.
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.
Yes, but I can not configure several cores.
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.
If I understand channels are identified by a string, so different 3pp will need to use a different string. With different cores each 3pp could use its own core without any trouble with other cores. What about using tags instead of strings to identify a channel?
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.
Let me say that I'm using two 3pp products that are using your library. They provide its own initial configuration and a backdoor to change on line the configuration. With several cores you can reach it, I don't know how you can do it with only one. Of course if your library provide only one code, I dont think 3pp library providers will use your library if they need its own configuration.
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.
Yes, but while one thread is reading other can not write. I think your design do not scale well. With several cores, you can reduce the contention. <snip>
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.
I understand. Vicente