[Fontconfig] Application startup performance

[Raimund Steger]

On Mon, 11 Jan 2016 19:28:44 -0800
Keith Packard <keithp at keithp.com> wrote:

> Akira TAGOH <akira at tagoh.org> writes:
> 
> > What I've tried to address those issues some times was happened when
> > installing some fonts packages in parallel and bring up multiple
> > fc-cache from scriptlets. and the directory information becomes
> > outdated because it is updated by installing fonts after collecting.
> > To explain things, assuming there are two processes of fc-cache A and
> > B say, run A first then B, and A finished then B. this doesn't break
> > anything. but when A takes a bit long time which has old information,
> > A rewrites old information after B. this breaks the cache. so that is
> > trying to check the dir timestamp is up to date after writing the
> > cache and then update if needed.
> 
> Those should still be caught by having the directory timestamps in the
> cache files, read before the directory is scanned so that changes after
> scanning starts eventually get caught.
> 
> > I still think we should have only single process to update caches to
> > keep consistency. though you disagree with that idea.
> 
> Keeping that invariant would require locking, which means either only
> updating caches when the user runs fc-cache, or doing locking within
> processes. The former means missing some font updates unless fc-cache is
> always run, the latter means risking locking up the desktop if some
> application fails.

The funny thing is I already see locking in the source:

(1) the older FcAtomic* locks which guard write to individual cache files in FcDirCacheWrite
(2) a newer call to fcntl in FcDirCacheLock which was introduced a year after the FcCacheDirsValid stuff, in ad9f5880502c9a3f8e7f8919336888ee056f17ba.

Now I got a feeling that this is slightly redundant. But independent of that, couldn't the lifetime of either one be extended to just after the (failed) mtime check beneath FcDirCacheRead, thus reducing the likelihood of a conflict? Or, maybe (2) had by itself alleviated the misbehavior reported a year earlier? It's invoked a couple of operations earlier than FcAtomicLock (before scanning font files).

Raimund


-- 
Worringer Str 31 Duesseldorf 40211 DE  home: <rs at mytum.de> 
+49-179-2981632 icq 16845346           work: <rs at interface-ag.de>