[cairo] glyph caching bug
Keith Packard
keithp at keithp.com
Tue Dec 28 15:35:29 PST 2004
Around 7 o'clock on Dec 29, TOKUNAGA Hiroyuki wrote:
> I implemented lock per entry tentatively, but encountered another
> problem. If all live entries are locked, _random_live_entry goes into an
> infinite loop. I think locking individual cache elements is hard to
> implement.
It seems like this can be avoided by allowing the _random_live_entry
function to fail and have the cache reduction loop terminate at that
point. We'll want to recode the _random_live_entry function to walk through
the entire cache instead of the current random probe technique though.
We could also keep track of the number of locked entries and stop purging
the cache when that number reached the number of live entries.
What I'm trying to avoid is forcing the whole cache to be locked
during all rendering operations; this will cause a large spike in memory
usage, instead of limiting memory usage to the maximum of the cache size
and the memory necessary to perform any single operation.
> I think it is difficult to regenerate a cache entry as needed. To know
> 'which entries are needed now' would be equivalent to lock individual
> cache elements. I want to propose another model, create entry
> explicitly.
Right -- because of multiple threads sharing the same cache, you have to
lock when you want to use any entries. Except for this, you could assert
that the last cache value fetched was always valid and make sure the code
consistently used only a single cache value at a time.
> If entry was created explicitly, there's no need to call
> create_entry/destroy_entry function in lookup function. We'll be able to
> write code like this.
>
> for(i=0; i<length;i++) {
> if(lookup(keys[i], &entries[i]) == NOT_FOUND)
> entries[i] = create_entry(keys[i])
> }
This doesn't appear to handle the case of multiple threads looking up the
same element in the cache simultaneously -- they'll both miss, and then
they'll both create the element and register it. I think we have to
atomically look elements up in the cache, creating them if missing.
-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/6df127b2/attachment.pgp
More information about the cairo
mailing list