On 1 July 2015 at 23:41, Andrey Semashev wrote:

On 02.07.2015 00:16, Andrew Hundt wrote:

...

I really only need some of the functionality of BOOST_LOG_TRIVIAL, perhaps plus loving to a file in addition to the console. However, my only true need is that all the work (or as much as possible) must be done in a separate thread so as not to slow the current thread down. Right now when I use BOOST_LOG_TRIVIAL as is it causes latency in my network communications which have soft realtime requirements so I've had to comment all of my logs out.

Is there a straightforward non-intrusive solution to having as much of the work as possible for boost.log be done in a separate thread?

Boost.Log does support asynchronous logging[1] although the current implementation might not suit well for realtime use either. It does have a lock in the internal record queue which is used to pass log records from the application threads to the log processing thread, although the critical section is minimal.

In order to enable async logging you have to configure the library by adding asynchronous sinks and probably some attributes on your application startup. You can keep using BOOST_LOG_TRIVIAL for emitting log records, the only change needed is the initial configuration.

[1] http://www.boost.org/doc/libs/1_58_0/libs/log/doc/html/log/detailed/sink_fro...

Just an additional suggestion for Andrew, if I understood correctly: depending on the context of the application, you might also want to just log on sockets, as suggested in the answer there: http://gamedev.stackexchange.com/questions/8691/logging-library-for-c-games I don't know if boost.log already have a sink like that but it might not be difficult to setup if you use boost.asio for example.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 29.07.2015 19:48, Andrew Hundt wrote:

However, I'm a bit unlucky because my application is implemented as dynamically loaded modules attached to another application, which there is a large warning about in your link. Do you know of any additional more detailed information about how best to ensure the data lifetimes are managed correctly so async sinks don't crash when modules are loaded or unloaded?

Well, the best way to avoid problems is to never unload modules. Most likely, you're dealing with a limited set of modules, so this won't result in resource leakage. Ensuring that module-specific data/code is no longer used can be very tricky and fragile and can affect not only Boost.Log. In general, you should avoid adding attributes, sinks or any kind of factories in your modules, or at least make sure they are removed before you unload a module. Also avoid global loggers because typically it's difficult to control which module creates them. And before unloading a module call logging::core::get()->flush() so that all buffered log records are processed. This may not be an exhaustive list, I may be forgetting something.