[cairo] glyph caching bug

[Keith Packard]

Around 4 o'clock on Dec 29, TOKUNAGA Hiroyuki wrote:

> Attached patch is a tentative implementation of cache locking. While a
> cache is locked, lookup function doesn't call destroy_entry function. I
> could confirm that the bug doesn't occur if this patch was applied. But
> cache will consume much memory than restricted by cache->max_memory
> untill unlock function is called. It may be a problem.

Ah, that makes tremendous sense.  Xft has locking of this sort to prevent 
precisely this problem.

> +void
> +_cairo_cache_lock (cairo_cache_t *cache)
> +{
> +    cache->locked = 1;
> +}

Should this be a counting lock instead?  iow, should it read:

  _cairo_cache_lock (cairo_cache_t *cache) { ++cache->locked; }

This way multiple agents (possibly multiple threads) could request that 
the cache be locked.  Alternatively, should we lock individual cache 
elements?  That might be more complicated, but would avoid having the 
cache explode.  You would fetch a cache element, and then at some future 
point you would release it so that it could be destroyed.

Hmm.  Now I'm a bit confused -- it seems like the cache entries should be 
regenerated as needed; if destroyed, they should be recreated at each step 
in the process.  Is there some place in the system which assumes the cache 
entries are still valid across multiple cache fetches?

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20041228/e7d0d7a0/attachment.pgp