Fix pango fontmap threading issue.

[JoakimSoderberg]

Since pango v1.32.6 pango_cairo_font_map_get_default returns a per thread fontmap. But since we're allocating this statically on the first call to rrd_init,
if we then try to access it again via another thread glib will get stuck in an infinte assertion loop.

Instead use pango_cairo_font_map_new() when creating the fontmap. This will not create a per thread version and glib will be happy.

Also added some extra locking whenever using the im->layout pango structure that uses the fontmap internally as a precaution.

This fixes #600

[oetiker]

• what is performance impact of this approach in the single threaded case ?
• at the moment librrdtool comes in two flavours, threaded and non threaded ... the major stumbling block apart from the one you just tackled is our use of getopt ... using popt might be an option for getting rid of this.
• please make sure the platform support the mutex lock by adding appropriate tests to configure.ac

[JoakimSoderberg]

Do you have any benchmarking script to check this, or do I have to roll my own?

I mean, I only added the locking because you mentioned it. I have not seen any issues related to it. I guess the fontmap isn't written to but simply read from by multiple threads? However I'm not familiar with all the glib reference counting, I guess that might create issues?

I'm not sure what you mean with the configure.ac comment. I simply used the built-in mutex_t wrapper. It is used in other places in the code. So what type of check is needed that isn't already done?

Regarding popt you could also checkout the command line parsing lib I've written if you're interested (https://github.com/JoakimSoderberg/cargo).

Replacing the entire use of getopt is a bit more than I will be able to do. This is basically a 1 line fix for an issue that causes a complete crash. The locking is just an extra precaution.

[oetiker]

the locking was just a guess ... no idea if it is necessary ... if not, all the better ...

about the multithreading thing ... thats from back in the day when not all platforms supported pthreads ... but I just realized that rrd_client.c is using mutex_t as well and it is included in the non-threaded version of rrdtool. So forget what I said about configure

I have no benchmarking code as such ... when I initially came up with this fontmap thing, I just create a loop to create a bunch of charts ...

And cargo ... didn't know about that one ...

[JoakimSoderberg]

Thanks for merging :)