<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - fontconfig update racy, causes update storm that freezes the desktop"
href="https://bugs.freedesktop.org/show_bug.cgi?id=100096#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - fontconfig update racy, causes update storm that freezes the desktop"
href="https://bugs.freedesktop.org/show_bug.cgi?id=100096">bug 100096</a>
from <span class="vcard"><a class="email" href="mailto:jan.steffens@gmail.com" title="Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>"> <span class="fn">Jan Alexander Steffens (heftig)</span></a>
</span></b>
<pre>(In reply to Akira TAGOH from <a href="show_bug.cgi?id=100096#c1">comment #1</a>)
<span class="quote">> Maybe not possible. that is why this is racy. one who knows the targeted
> directories is updated is only one or a few where is kicking updates. but it
> isn't necessarily true that the updated caches contains the updates coming
> during updating.</span >
I wasn't looking for a perfect solution. Note that in my tests I was only
touching one directory twice within 100ms, yet every process loading fontconfig
insisted on regenerating the cache for this directory in sequence, taking over
two minutes in total. The second regeneration should have been the last (for
the latter change), but it wasn't.
<span class="quote">> If the updates on fonts directories is often happening, maybe good to
> increase the rescan interval in the config to check.</span >
I think this would make it happen less often, but still just as badly.
<span class="quote">> other option is to
> implement a feature stops updating caches in fontconfig during loading
> caches. this will prevents unexpected freeze on runtime. but someone needs
> to take care of the outdated caches instead of fontconfig and re-create
> caches as needed then.</span >
Right. The perfect solution for me would be:
- libfontconfig only watches config and caches for changes, never font dirs
- system caches are only ever regenerated manually (e.g
via package manager)
- user caches are regenerated manually or by gnome-settings-daemon when user
fonts change
This should totally avoid unexpected stalls because the applications do not
attempt to scan the fonts. However, I don't know how to deal with apps that
need older cache versions not produced by the system.
Another mitigation approach would be doing the scanning asynchronously, in a
worker thread.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>