[Boost-users] Boost.Log

Subject: [Boost-users] Boost.Log
From: Leon Mlakar (leon_at_[hidden])
Date: 2015-07-27 15:33:50

Hi,

I've started looking into Boost.Log as one of the possible solutions for 
out multi-platform project with, alas, Microsoft Windows being one of 
the them platforms. While the solution is multi-threaded, we are trying 
to avoid any thread synchronization on common resources by using 
sequential task queues associated with these resources. The resulting 
internal architecture is thus fully asynchronous with no synchronization 
points between worker threads.

So I'm trying to fit Boost.Log into this, and the documentations, while 
exhaustive, still leaves some questions unanswered. Or perhaps I missed 
them. For instance, as far as the sources go, the library offers two 
logger flavors ... thread safe (I'm assuming guarded by mutex) and 
single threaded variants. I'm inclined towards using the latter 
(obviously, don't want to sync on mutex) but that would mean creating 
thousands of logger instances and I don't have a feeling how heavy or 
lightweight the logger is. Hence the first questions:

1. How heavy the logger is and what would it mean to have thousands of 
them around?
2. Why is there a need for _mt variants? Solely to protect logger 
internal data or to synchronize operations towards the core?
3. Is there anything  else the loggers do apart from storing source 
specific attributes and associating them with the record, and serving as 
an open/push frontend to the core?

And since the alternative is to directly use the core rather than going 
through the loggers, this immediately raises the next question:

4. are the following core operations internally synchronized: 
core::get(), core::open_record(), core::push_record()?

And the final question:

5. If we were to go with using the core directly, would it be better to 
store shared pointer obtained via core::get() or to call core::get() for 
each log (basically, whether is it okay to store shared pointers to core 
up until the start of the end of the destruction sequence of the process?

I think the sinks are more thoroughly covered in the docs. I'm unsure at 
the moment whether to use one of those already available in the library 
with the asynchronous frontend, or go for the unlocked frontend with the 
own backend associated with the task queue. While I'm aware I did not 
provide enough information to directly ask the question, any thoughts on 
this would nevertheless be welcome.

Thank you and best regards,

Leon