[cairo] Static caches and thread-safety

Bill Spitzak spitzak at d2.com
Fri Nov 12 11:15:09 PST 2004


On Thursday 11 November 2004 07:09 pm, Carl Worth wrote:

> I'm half tempted to move the caches down into cairo_t and encourage
> users to clone from a single call to cairo_create if they want to get
> all the sharing benefits...
>
> Keeping locking out of cairo definitely seems appealing. And I wouldn't
> guess that it would be common for less-informed users to want to make
> lots of simultaneous cairo_t objects. Stupid?
>
> Thread-local storage?
>
> Nothing seems perfectly clean here. Dirty, dirty...

It seems to me that if a cache is useful, it should be shared amoung 
everything and thus there is exactly one cache. Even if different things are 
needed in the cache for different surfaces, a hash lookup that includes the 
surface-id would be more efficient than havng a per-surface cache.

The interface to a cache may be something like this, notice that there is no 
"which cache" argument because it assummes there is only one cache. However 
the cairo_t argument could be used to implement multiple caches if necessary:

_Font* font = _get_font(cairo_t, stuff...);
_Image* image = _get_glyph_image(cairo_t, font, data);
draw_the(image);
_release_glyph_image(cairo_t, image);
_release_font(cairo_t, font);

The idea is to provide a call to the cache that indicates when you are done 
with an object, so it can be unlocked. _release_glyph_image indicates that 
the image can be thrown out of the cache. This can be a no-op if the cache 
never actually throws anything away, or if _release_font is the actual call 
that gets things out of the cache. These should be inline macros/functions so 
that they can be fast if they are trivial. Since this interface is entirely 
internal using macros is no problem.



More information about the cairo mailing list