Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at