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 13:50:49

Vicente Botet wrote:

> 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?

The channel can be identified in any way. In fact, the channel 
identifier is no different from any other attribute value, from the 
library perspective. The channel_logger provided by the library uses 
strings because it is the obvious and commonly used type for this purpose.

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

I think that a good library should support customizing the logs it 
produces. In your example, the third party libraries should act as log 
producers and support customizing their output. For instance, the 
libraries can expose APIs to set up their particular channel names, 
which will allow to split their logs into different sinks, if needed.

Your application, which uses these third party libraries, should act as 
a configuration master and set up the sinks, filtering and formatting 
the way your application needs (note that it's not the way either of the 
libraries may impose). The application may use logging, too, but that's 
irrelevant to the point: it is the application who has to control 
logging, not the libraries.

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

Like I said, acquiring the write-lock is quite rare. I'd say, typically 
you will only need it during the initialization phase.