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