[cairo] Win32 thread-safety

Adrian Johnson 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 mailing list