Is it possibly to get a stacktrace to file from a signal handler?

I got a great question from a reader of the g2log article on CodeProject regarding g2log’s implementation of a crashhandler.

[…]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?

Continue reading

Posted in Uncategorized | Leave a comment

G3log: Asynchronous logging the easy way

It is my privilege to present g3log, the successor of g2log that has been brewing since the creation of the g2log-dev.
G3log is just like g2log a “crash-safe asynchronous logger“. It is made to be simple to setup and easy to use with an appealing, non-cluttered API.
G3log is just like g2log blazing fast but with approximately 30% or faster LOG processing. G3log adds some important features:

  1. Completely safe to use across libraries, even libraries that are dynamically loaded at runtime
  2. 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.
  3. G3log provides faster log processing compared to g2log. The more LOG calling threads, the greater the performance difference in g3log’s favor.

G3log is just like g2log released as a public domain dedication. You can read more about that here:

So, don’t let slow logging bog your performance down. Do like developers, companies and research institutes are doing all over the globe, use g3log. Want to know more? Read on …

Continue reading

Posted in Uncategorized | 2 Comments

Concurrency : concurrent<T> part 2

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.

The finished and improved concurrent<T> can be found at:

Continue reading

Posted in C++, concurrency, Software Engineering | 2 Comments

C++11 template tricks: Finding the return value type for member function-pointer

[Shameless Plug Warning] :
You have until August 31st, 2017 to try out NetMon and participate in LogRhythm’s Network security contest. Win up to $18,000 when applying your scripting skills to detect network vulnerabilities.  See for more information.

Using templates you can deduct the return type from a non-member function fairly easy.

#include <type_traits>
int foo(int i) {   return i;  }

int main() {
   static_assert(std::is_same<decltype(foo(123)), int>::value, "");

Finding the return type for a member function is a little trickier. You can do it in various ways. decltype can still be used but now we also need the power of std::result_of

Continue reading

Posted in C++, coding, concurrency, Uncategorized | 1 Comment

Concurrency : Concurrent<T> part 1

Herb Sutter presented in C++ and Beyond 2012 a very useful concurrency pattern that is an improvement from the “active object“.

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 API call is always through a lambda or a std::function.  

Continue reading

Video | Posted on by | 1 Comment

2013 in review

The 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!


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.

Click here to see the complete report.

Posted in Uncategorized | Leave a comment

G2log with Clang., Now with all the bells and whistles

At reddit I found that it was possible to get futures and std::thread to play nice on Linux/Clang.

I have updated my previous post “g2log with Clang++” with the details so that you can get Linux/Clang (and g2log) with all the bells and whistles of C++11.

All the clang limitations on G2log is therefore removed and Clang users can now enjoy the fully featured G2log.

I am currently working with G3log  and Clang. So far G3log supports Windows (VS2013, mingw) and Linux (g++) and I hope to get Clang up and running.

Posted in C++, G2log | 10 Comments