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-30 11:01:37

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, January 08, 2010 3:14 PM
Subject: [boost] [log] Release Candidate 4 released

> 
> I'm proud to announce that I've released the fourth candidate of 
> Boost.Log for the review.
> 
> There were many improvements since the passed year of development. Many 
> of them reflect the discussion of RC3. Here's a short list of major changes:
> 
> * Added a new ordering asynchronous sink frontend.

> The docs are also available online here:
> 
> http://tinyurl.com/5e4fd7
> 

Hi, I'm interested in knowing how the Asynchronous sink frontend is implemented. Do you use a single queue or one queue by thread?

In "Why log records are weakly ordered in a multithreaded application?" you present two possible solution:

* Strict serialization ( drawback:log records that otherwise could be processed concurrently would have to go serial)
* Ordering asynchronous sink frontend (drawback: the order is not completly ensured if a thread blocks during more than the latency parameter)

Maybe we can mix both. We can manage with a single log counter that is increased each time a log is done. The time spent to increase this counter atomicaly shouldn't have a deep impact on the concurrency of logs, isn't it? Each log will have a counter attribute that will ensure a complete order of logs. We could have an asynchronous sink that will pass the logs to the back-end in the order given by this counter. Of course this will introduce a latency between the source logging and the time it is given to the back-end sink, but any asynchronous sink will suffer form the same symptom.

Do you think that something like this could be included in your library?

Good work :),
Vicente