Bug 100096

(In reply to Jan Alexander Steffens (heftig) from comment #0)
> Maybe fontconfig can at least reduce the impact by rechecking whether the
> cache is up-to-date after acquiring the lock?

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.

>                                               This way there should be only
> one unexpected cache update instead of a dozen or more.

Thus this isn't true.
If the updates on fonts directories is often happening, maybe good to increase the rescan interval in the config to check. 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.

One proposed implementation: https://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=disable-auto-update

On this way, most applications turns off the cache updates on loading and have a process to update. in this case, GSD. once updates is done, GSD could notifies to applications to force-reload caches.

(In reply to Akira TAGOH from comment #1)
> 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.

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.

> If the updates on fonts directories is often happening, maybe good to
> increase the rescan interval in the config to check.

I think this would make it happen less often, but still just as badly.

> 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.

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.

I suppose this should be improved by 2.13.0. please test and see if that fix is good enough.

Yep, I still get minor hiccups but it looks good enough, thanks.