[boost] Re: Logging Library -- Formal Review Request

From: Daniel Frey (d.frey_at_[hidden])
Date: 2005-04-30 14:53:14

Gennadiy Rozental wrote:
>>>Gennadiy: to do what you suggest would seem to me to require (a) no
>>>buffering and (b) an interface which is likely not thread-safe.  Or am
>>>I missing something.
>>
>>Gennadiy, correct me if I'm wrong but as you wrote your post as a reply
>>to mine, I can see a connection: You seem to prefer the unbuffered
>>logging to have at least the partial information before an exception
>>occurs and to avoid complexity in the implementation of the logging
>>library by avoiding the buffering code, right?
> 
> 
> I did not had any buffering in mind. See my other post. May be you could 
> explain me more how buffering affect order of log entries in stream.

Consider threading and how we can avoid problems with multiple threads
writing log messages. One option is to simply lock the log stream while
it is in use. You can output the log messages part bit by bit now, but
this might lead to deadlocks. Example:

BOOST_LOG(app) << "Hello" << f() << g() << "world!";

The BOOST_LOG() locks app for other threads. It is unlocked when the
complete expression is evaluated. This can be easily achived, but what
if f() makes another thread output something to app? And g() waits for
the result from f()'s subthread? => Deadlock.

Another choice is not to lock app. Actually, this is preferable anyway
as locking should be avoided whenever possible. What we need now is a
way to output the log-message as an atomic operation. This can only be
done when we are able to cache the complete message before flushing the
buffer. But then, this cannot be done with a fixed sized buffer. As a
consequence, I think that a fixed sized buffer potentionally leads to
intermixed logging in a multithread environment. Or is there something
I'm missing?

Regards, Daniel