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-09 06:20:36

On 01/09/2010 12:45 PM, Edouard A. wrote:

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

Apart from sinks, there are two possible locks: the logger, if it's a 
thread-safe one, and the logging core. Both locks are shared ones, so in 
the common case (you don't modify the core or the logger concurrently 
while emitting log records) you won't block there.

It is possible to block in a sink, if it's a synchronous one. If you 
have several sinks, the core will attempt to distribute records among 
them so that blocking is minimized. But you use asynchronous sink, which 
in Boost.Log also uses a non-blocking queue to pass log records to a 
dedicated thread. So you should be good here, too.

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

Well, that's a complex question. Depends on when to consider the 
"packet" built. Log records pass several stages before being consumed by 
sinks, such as filtering, message formatting and sink-specific 
formatting. The latter one is done in the dedicated thread in case of 
asynchronous sink. During these stages and in between of them the memory 
may be allocated. Sinks themselves typically don't allocate memory, but 
that is not always true.