[cairo] Win32 thread-safety
ajohnson at redneon.com
Fri Nov 6 06:38:32 PST 2009
Sven Goericke wrote:
> To get closer to the problem i decided to compile and debug the stuff
> with MSVC (Visual Studio 2008). I found out the "bad_alloc" exception
> was thrown by the cairomm-library (CAIRO_STATUS_NO_MEMORY). But i still
> didn't have an idea why. Because the errors are "random" ones it was
> hard to find the problem. The first hint i got was that the exception
> always was thrown if i did anything with text (get_text_extents(),
> show_text() mainly). A hour ago i just found that one of my
> drawing-threads has thrown the exception and another called
> "cairo_show_text()" the same time. So i came to the conclusion that
> there *must* be a probelm with text-handling on Win32 systems. Btw., at
> the moment i run up to 8 threads that use cairo and growing.
> So i tried a "simple" approach and add a global Mutex to my plugin and
> cover every text-related stuff in my code by this Mutex. And surprise
> surprise, this helps. But also reduces Performance a bit in the
> Application, saying X-Plane.
I tested some code based on the pthreads-show-text test and it appears
that _get_global_font_dc () is the problem. Changing the win32 font
backend to make _get_global_font_dc () create a new DC instead of
reusing the same one and freeing the DC at the end of each function that
called _get_global_font_dc () makes my test case work.
Also the documentation for CreateCompatibleDC() states that the thread
that calls CreateCompatibleDC() owns the DC. When the thread is
destroyed the DC is no longer valid.
I'm not sure what the performance impact of creating a new DC each time
is is required. Should the DC be stored in thread local storage?
More information about the cairo