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

Subject: Re: [boost] [log] Release Candidate 4 released
From: Edouard A. (edouard_at_[hidden])
Date: 2010-01-09 04:45:29

>Yes, I intend to add this section to the docs later. There has been some 
>performance testing with comparison to log4cxx. You may find interesting 
>the discussion in this forum thread:
>
>http://tinyurl.com/ya85vwf

Hi,

First of all thanks for submitting this log library to boost, I'm really
happy to see you're staying committed to this project. A log library in
boost is really something we miss!

We're currently using a home-baked asynchronous log system, which is
implemented as a lock-free queue sending log packets to a background log
thread. Nothing fancy as we don't have to solve a general case like your
library. 

Basically, we have a free function called "emit" that uses old school
"printf"-like formatting, it synchronously builds the packet and then sends
it to the queue which is eaten by the logging thread. The thread then sends
the packet to all the sinks in parallel.

Our constraint is that the log engine must not lock at any time and must not
allocate memory once the packet is built.

Do you think it would be possible for us to simply write a log frontend
using the lock-free queue and still respect our constraints? Put
differently, has your log-engine other internal locks (apart from potential
I/O locks, of course)?

Is there dynamic memory allocation going on inside the engine? That is, once
I built my "log packet" is there going to be any dynamic memory allocation?

Please don't see that as requests, we have very bizarre and specific needs,
we'd just like to see if switching to Boost.Log is a possibility.

Regards.

-- 
EA
 
 
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4755 (20100108) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com