Is the Cairo Graphics Library Reentrant?

Question

If I use two different cairo_t (and related cairo_surface_t etc) objects in two different threads, can I be guaranteed that there will be no race conditions due to shared global state?

Can I also formally pass a cairo_t object from one thread to another without any unexpected behaviour (possibly arising from thread local storage)?

Answer 1

This bug-tracking discussion should answer your questions : https://bugs.freedesktop.org/show_bug.cgi?id=74355

1. Cairo should be re-entrant

Uli Schlachter 2014-02-03 18:25:06 UTC

(In reply to comment #0)

1. share a single cairo_surface_t between the threads, and have each thread draw using its own cairo_t. This crashes, but maybe I'm hoping for too much (although an image surface is essentially just a big array of bytes that should be writable from multiple threads).

Sure, just an array. And this works as long as you expect anything like useful results. Cairo is supposed to be thread-safe as long as the threads don't share any state (well, this is an oversimplification, but your first approach isn't supposed to work).

2. Thread local storage can crash Pixman

Søren Sandmann Pedersen 2014-02-17 16:49:02 UTC

It is possible that pixman's support for TLS on Windows is simply buggy; it may be that not a lot of people have been using pixman in a multithreaded way on Windows (or have worked around the problem in some way). We will need some kind of way to reproduce the issue to know.

In pixman 0.32.0 and later there is a test program called 'thread-test' that may reproduce this issue if you can get it running on Windows.

As a policy, you should always consider third parties libraries not-tread safe, until proven otherwise.

Answer 2

Since your title asks for reentrancy: There aren't many callbacks in cairo, but as long as you don't cause any recursive callbacks, you should be fine.

Cairo definitely isn't signal-safe and I can't really imagine it being so.

And for your actual question about threads: There isn't that much global state in cairo and most of that is protected via apropriate mutexes. There were/are some bugs with font locking. If you stumble upon thread safety problems and can write a not-too-huge, self-contained program that reproduces the problem, the problem should be quickly fixed. So any thread-safety issues are considered bugs.

And yes, this does not apply to sharing state between threads. Only implicitely used global state is protected. You cannot use any object that cairo hands to you in multiple threads at the same time. But you can freely move an object between threads.