Created attachment 85352 [details]
Make usage of freetype thread safe
Current freetype backend is not thread safe. It can cause segmentation fault when threads are not properly handled by applications which use cairo (see https://bugzilla.redhat.com/show_bug.cgi?id=678397 and its duplicates).
Attached patch tries to fix this problem by creating FT_Library object for each thread. This is recommended solution by freetype (http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/include/freetype/freetype.h#n1684).
It adds a hash table to which FT_Library is added if a new thread needs one. Thread IDs are used as keys for this table.
Unfortunately that FreeType "recommendation" is red herring. First, people are free to pass around FT_Face among threads, and second, we will be leaking stuff this way, unless we add proper TLS support.
At any rate. I suggest we use cairo for all glyph rasterizer instead.
Chris, any chance you have some time to think about this?
*** Bug 81874 has been marked as a duplicate of this bug. ***
Looks like copying thread-local storage macros from pixman-compiler.h and using them to use per-thread FT_Library might easily get most of this resolved. I can take a look if no one else steps in.
(In reply to Behdad Esfahbod from comment #4)
> Looks like copying thread-local storage macros from pixman-compiler.h and
> using them to use per-thread FT_Library might easily get most of this
> resolved. I can take a look if no one else steps in.
had you time to look at this already?
So, I ended up trying to fix this in FreeType. Have made huge progress so far. Here's a tree:
And here's a standalone test:
There's still some more work to do. I can't yet understand this crash for example:
I now have a complete patchset up here:
Will be sending upstream soon.
Patchset is now upstream in FreeType.
(In reply to Behdad Esfahbod from comment #9)
> Patchset is now upstream in FreeType.
Thank you very much for all the effort you've put into this!