----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> 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:
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