[Fontconfig] Race condition on updating cache

[L. A. Walsh]

Akira TAGOH wrote:
> That also works but we need to support the parallel updates on
>> fc-cache by threading then. otherwise it's quite stressful to wait
>> for. but it may takes more time if the directory structure where is
>> updating is too deep, because there are no way to know how many sub
>> directories it contains until a cache is updated. so just updating
>> twice seems realistic at this moment. this may be a todo task for
>> future improvement.
I don't think scanning the directory tree in the font dir
is a problem.  On a tree with 35,632 paths (27066 uniq inodes before
deduplication), (this is my "/usr/share/fonts" dir, BTW), it took
an app(my dedup script in perl) ~8s to walk my font-dir tree
w/a cold cache.

Have you thought about using async I/O... maybe w/an event loop?

find took 4.2s to go through my /usr/share/fonts on a cold cache.
an async tree scan w/cold cache took took about 2.0s..

(FWIW, if timing, I run this dropcaches function):

  function dropcaches() {
    echo -n "3"|sudo dd of=/proc/sys/vm/drop_caches
  }


I just reran my dedup script on the fontdir (hardlinks dup files) so
it could be faster...  but I don't think fontconfig checks the
inode#'s to see if there are dups to skip reading?
Does it? 

For dedup to walk /usr/share/fonts and find dups:

Ishtar:/usr/share/fonts> time dedup .
Paths: 35632, uniq nodes: 27066, total_size: 11.4GB (11.6GB allocated).
Explore & Sort finished at 9.403s  <<<<<<<<<<<<----(7.924s for walk+sort)
Creating HoSSL finished at 1.479s
Finished w/20189 nodes & 7.7GB space (6877 new 
links)                                  
3.9GB in 6880 duplicate files found in 104.63 seconds.  (114.04s total)
114.33sec 31.51usr 14.56sys (40.30% cpu)

In comparison, font-config rebuilding that
cache takes over ***14 minutes*** of cpu time (I didn't have a
wall clock running on it; so just read the cpu), but  it was
at least 14 minutes, guaranteed (while dedup was only 40% cpu
bound, it is mostly cpu bound).