Re: [boost] [log] Release Candidate 4 released

Subject: Re: [boost] [log] Release Candidate 4 released
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-01-31 08:40:55

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, January 30, 2010 11:40 PM
Subject: Re: [boost] [log] Release Candidate 4 released

> 
>>> Yes, I have considered this idea. IMHO, it won't give much
>>> performance benefit, compared to a single lock-free queue, unless
>>> all your application does is logging alone, from dozens of threads.
>>> I did not experiment, though, so I don't have numbers behind
>>> myself.
>>>
>>> I have plans of redesigning the queue in order to allow to limit
>>> its growth, which may be required in heavily loaded applications.
>>
>> This is a good idea. In this kind of context it would be worthwhile
>> to have some mechanism to decide which log records should be lost, in
>> case there is not enough place, severity could be an important
>> factor.
> 
> No, I don't plan dropping log records.

If you limit its growth, what will you do with the new records when there will not be more place?
 
>>> Per-thread queues would complicate this addition.
>>
>> Why?
> 
> Because it gets more difficult to determine the total number of queued 
> records. Without introducing a shared locked counter, that is.

Sorry to insists, why do you want to determine the  total number of queued records?

>>> Well, from the observer's point of view, records that have the same
>>> time stamp were emitted simultaneously. It's undefined which of
>>> them happened first, thus no point to define their order in log.
>>> One might want to improve the time stamp precision to get a more
>>> crisp picture of inter-thread relations.
>>
>> This is thru when the logs are done by different threads, but not
>> when they are doen by the sme thread. If the user do
>>
>> log A log B
>>
>> The user expects A is logged before B even if these logs share the
>> same time stamp.
> 
> Log records of the same thread are always ordered. You don't need an 
> ordering frontend to achieve that.

Does asynchronous_sink provides already this?

How do you ensure  Log records of the same thread are always ordered?

>>> However, you are free to order records as you will. You can define
>>> the ordering based both on the time stamp and the record counter.
>>
>> I agree. I have to say only that I would expect the library provides
>> this by default.
> 
> There can not be such a default, since there are no default sinks and 
> attributes. Thus the library cannot guess what attribute values it 
> should use for ordering and what types will they have.

Ok I see. Can the creation of a sink force the association of some attributes to the core if not already associated. 

I would like try to add a ordering_asynchronous_sink that needs an order that depends on two attributes: local_clock and a counter. How can I do this? 

>>> You can't implement a complete order, just the order within an
>>> ordering window. But yes, the main aim of this functionality is to
>>> maintain chronology of log records.
>>
>> So, do you think it is worth opening this order to the user? Does the
>> library provives at least one order that maintain chronology of log
>> records? If yes, this should be the default behavior. If I have
>> undestood the user needs to state explicitly an order, isn't it?
> 
> The ability to order records is available. Yes, the user has to set up 
> the ordering explicitly, which includes specifying the attribute value 
> name, type and the predicate. And yes, there are tools to simplify this.

Please, could you point me to the attribute and the predicate provided by the library that maintain chronology of log records?
What other complete orderings do you have in mind the user could want? a concrete case?

Just a last question is the counter attribute thread-safe?

Best,
Vicente