Poco log lines from different thread overwrite each other

Question

I have two different threads both logging to separate Poco::WindowsColorConsoleChannel channels.

However sometimes the messages appear interleaved, e.g. if one thread logs aaaaaaa and the other logs bbbbbbbb then the screen may look like abbbbbaaaaaabbb.

The threads are using completely different Logger objects and different channel objects.

The same thing happens if using the default channel. The problem is particularly pronounced with the color console channel as it makes the colours look like the wrong lines are being coloured.

Is there a way to make each log line 'atomic'?

Note: I haven't yet checked to see if the same problem occurs when logging to a SimpleFileChannel, but if so then I would need a solution for that too :)

Answer 1

ConsoleChannel logging operation is protected with a static FastMutex. However, to provide proper Unicode text logging, on Windows the ConsoleChannel defaults to WindowsConsoleChannel, which converts UTF-8 to UTF-16.

So, the Application::logger() will likely have the default WindowsConsoleChannel, while the thread has ConsoleChannel (or Color* versions thereof); in any case you must have a mix of different channels to see the effect you are describing - although the destination is the same, you are logging through different channels, which are protected by different mutexes. I think it would make sense for Poco to protect all console channels with a single static mutex to avoid problems like this.

Given all this, the code example you posted above should work fine even without the custom synchronization scheme.

Note also that, whenever you are logging to the same console channel type, your threads will be waiting for each other during every log operation. To avoid the bottleneck, you may consider using AsyncChannel.

(Simple)FileChannel is protected by a non-static FastMutex, so it will not suffer from the same problem as long as each thread is logging into its own file or they all log to the same file through the same channel instance. I never tried the latter but intuitively it does not sound like the right thing to do.