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-31 09:12:08

On 31.01.2010 16:40, vicente.botet wrote:
>>> 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?

The frontend will block until the dedicated thread consumes some of the 
queued 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.
>
> Sorry to insists, why do you want to determine the  total number of
> queued records?

Is there another way to implement a bounded queue?

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

All sink frontends provide this guarantee.

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

Because I don't reorder them. The only way one could counter that is to 
specify such an ordering predicate to the ordering frontend, that would 
reorder records in reverse. But that would simply garble all the output.

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

No, these operations are not related.

> 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?
>
> Please, could you point me to the attribute and the predicate
> provided by the library that maintain chronology of log records?

There is this utility:

http://tinyurl.com/y9sove6

The way it's used with the ordering frontend is shown here:

http://tinyurl.com/ycowsfy

It does not immediately allow to order by more than one attribute value, 
but you can write your own ordering function that accepts two records 
and returns bool:

   bool my_order(record const& left, record const& right)
   {
     ptime left_ts, right_ts;

     typedef record::values_view_type values_view_type;
     values_view_type::const_iterator
       it_left = left.attribute_values().find("TimeStamp"),
       it_right = right.attribute_values().find("TimeStamp");
     if (it_left == left.attribute_values().end() ||
       it_right == right.attribute_values().end())
       throw std::runtime_error("Time stamp not found");

     left_ts = it_left->second->get< ptime >().get();
     right_ts = it_right->second->get< ptime >().get();

     if (left_ts < right_ts)
       return true;
     else if (left_ts > right_ts)
       return false
     else
     {
       unsigned int left_counter, right_counter;

       it_left = left.attribute_values().find("LineNo"),
       it_right = right.attribute_values().find("LineNo");
       if (it_left == left.attribute_values().end() ||
         it_right == right.attribute_values().end())
         throw std::runtime_error("Line counter not found");

       left_counter = it_left->second->get< unsigned >().get();
       right_ts = it_right->second->get< unsigned >().get();

       return left_counter < right_counter;
     }
   }

> What
> other complete orderings do you have in mind the user could want? a
> concrete case?

User might want to store log records in an associative container. In 
this case, it might be useful to have the ability to search for a record 
by any attribute value attached to it.

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

Yes, it is.