Re: [boost] [log] Review-ready version in the Vault

Subject: Re: [boost] [log] Review-ready version in the Vault
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2009-02-12 13:20:34

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
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