<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Make fontconfig cache relocatable" href="https://bugs.freedesktop.org/show_bug.cgi?id=101889#c84">Comment # 84</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Make fontconfig cache relocatable" href="https://bugs.freedesktop.org/show_bug.cgi?id=101889">bug 101889</a> from <a class="email" href="mailto:alexl@redhat.com" title="Alexander Larsson <alexl@redhat.com>"> Alexander Larsson</a> <pre>Actually, not even that is enough to make it threadsafe. Fundamentally, you can't do something like return the values from FcHashTableFind() while at the same time allow replacing them, because at any time after you looked up a value it may become replaced and the value freed. This is true even if you have a value_copy_func, for example in FcHashTableFind, where the value in the table could be freed by another thread doing a replace inbetween reading the bucket->value and calling value_copy_func on it. Also, if you're doing atomic replace on bucket->value, you need to pair that with reading it with get_atomic. I'm not sure why you are writing lock-less code like this, it is a *lot* of work to make it correct, especially on non-intel boxes that don't have strong ordering, and adding a bunch of atomic ops everywhere is likely to be slower than just a single lock around the entire thing unless it is actually highly contended. Anyway, given the current API i think the only solution is to make replace just add *more* values for the key, basically making FcHashBucket->value a list. That way old values are not freed, but just "deprecated".</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>