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

Subject: Re: [boost] [log] Review-ready version in the Vault
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-12 12:55:31

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.InterThreads
> 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.