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

Subject: Re: [boost] [log] Release Candidate 4 released
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-01-30 17:40:38

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

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

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

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

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