[…]new, delete and IO operations are not safe in signal handlers and could cause unpredictable behavior. I checked your implementation and maybe I am wrong but it seems this is exactly what you did (write to file/ empty queue within the signal handler). Is that by design, am I wrong or you missed this.

Of course the reader was completely right. It is not safe, it is one of those “please don’t try this at home” kind of things. With “safe” I here mean, “Posix guaranteed safe“.

Is there any “safe” way at all of getting the stacktrace to file after a fatal signal has happened?

G3log is just like g2log blazing fast but with approximately 30% or faster LOG processing. G3log adds some important features:

Completely safe to use across libraries, even libraries that are dynamically loaded at runtime

Easy to customize with log receiving sinks. This is the major feature of g3log compared to g2log as it gives the users of g3log the ability to tweak it as they like without having to touch the logger’s source code.

concurrent<T> part I described a powerful wrapper that made all calls to the object to be executed asynchronously and in FIFO order. Using a lambda call made it easy to bundle several actions on the concurrent<object> in one asynchronous operation.

This is great news for coders who wants a foolproof background threaded object that manages well initialization, shutdown and with a thread-safe call API. No more start-up races or weird shutdown behaviour!

Sutter’s concurrent<T> is a powerful pattern. With some small changes and g3log tech import, we can boost it to be even better. Let’s make it foolproof to use, easier to call and with the power to handle derived types and not only concrete types.

Let’s take a step towards making concurrency as easy as we want it to be. At the same time let’s take a look at how std::packaged_task, std::future and std::exception_ptr are glued together to make this work great as well as being coder-user-friendly.

concurrent wraps any objecft and all calls to the object will be executed asynchronously and in FIFO order.

Basically it is an improved active object that can wrap any object. The improvement from the active object pattern is that the boiler plate code to get an object asynchronous is completely removed! The asynchronous function call on the object will be forwarded from a wrapper object to the actual object through a message queue.

// "hello" will be copied into a temporary std::string
// that will the input to the concurrent
// wrapper
concurrent<std::string> async_string{"hello"};
// Calling it is done through a lambda. The call
// is asynchronous. The job is executed in a background thread
async_string( [](std::string s) { s.append("world"); } );

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog. It was a crazy year with relocating the whole family to the USA and trying to find a the best location and company to work for. The blog was not that active during 2013 but will be more active in 2014.

Coming up is the pending, official, release for G3log with some C++11 concurrency tech that might interest some coders.

A whole other story that is in the queue of tales to write is the whole moving process and what we learned from it. There should be some goodies there for other people who is in the process of moving across the pond.

Below is an excerpt of the blog report.

Happy New Years!
Kjell

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 28,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 10 sold-out performances for that many people to see it.