Re: Application startup performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.

I still think we should have only single process to update caches to
keep consistency. though you disagree with that idea.

On Tue, Jan 12, 2016 at 1:34 AM, Behdad Esfahbod <behdad@xxxxxxxxxx> wrote:
> On 16-01-11 04:28 PM, Behdad Esfahbod wrote:
>> On 16-01-11 03:30 PM, Keith Packard wrote:
>>> Behdad Esfahbod <behdad.esfahbod@xxxxxxxxx> writes:
>>>> Humm.  I don't know when things changed, but as far as I understand, we
>>>> readdir() every time; the cache just caches the patterns for each
>>>> file.
>>> That's wrong -- fontconfig knows all of the directories in the hierarchy
>>> and should be able to just stat each of them; if none of the existing
>>> directories have changed, then no new fonts could have been added to the
>>> system. Stat'ing a few known directories should suffice to track whether
>>> the cache is up to date. And, it used to work this way, so something has
>>> been broken.
>> Right.  Seems to be introduced by the never-ending series of "fix race
>> condition" patches.  In particular:
>> commit f44bfad235e63bb792c38e16ae1fbd281ec1453b
>> Author: Akira TAGOH <akira@xxxxxxxxx>
>> Date:   Thu Jun 5 19:06:02 2014 +0900
>>     Workaround another race condition issue
>>     See
> Akira,
> Do you remember what the issue actually was?  Neither the commit log nor the
> bug history really mention that!
> b
>> Here's the stacktrace:
>> #0  FcStat (file=0x626710 "/home/behdad/.fonts/ArabicSansBY-Regular.otf",
>>     statb=statb@entry=0x7fffffffcd60) at fcstat.c:127
>> #1  0x00007ffff7ba7e3f in IA__FcFileIsDir (file=<optimized out>) at fcdir.c:36
>> #2  0x00007ffff7ba84a1 in FcDirScanConfig (set=0x0, dirs=0x625a80,
>>     blanks=<optimized out>, dir=<optimized out>, force=<optimized out>,
>>     config=0x603040, scanOnly=1) at fcdir.c:309
>> #3  0x00007ffff7ba85c3 in FcDirScanOnly (dirs=dirs@entry=0x625a80,
>>     dir=dir@entry=0x609390 "/home/behdad/.fonts",
>>     config=config@entry=0x603040) at fcdir.c:348
>> #4  0x00007ffff7b9f316 in FcCacheDirsValid (config=config@entry=0x603040,
>>     cache=cache@entry=0x7ffff7f9d000) at fccache.c:604
>> #5  0x00007ffff7b9fd1d in FcDirCacheMapFd (config=config@entry=0x603040,
>>     fd=fd@entry=3, fd_stat=fd_stat@entry=0x7fffffffcf40,
>>     dir_stat=dir_stat@entry=0x7fffffffcfd0) at fccache.c:684
>> #6  0x00007ffff7b9fd69 in FcDirCacheMapHelper (config=config@entry=0x603040,
>>     fd=fd@entry=3, fd_stat=fd_stat@entry=0x7fffffffcf40,
>>     dir_stat=dir_stat@entry=0x7fffffffcfd0,
>>     closure=closure@entry=0x7fffffffd0e8) at fccache.c:725
>> #7  0x00007ffff7b9f788 in FcDirCacheProcess (config=config@entry=0x603040,
>>     dir=<optimized out>,
>>     callback=callback@entry=0x7ffff7b9fd60 <FcDirCacheMapHelper>,
>>     closure=closure@entry=0x7fffffffd0e8,
>>     cache_file_ret=cache_file_ret@entry=0x0) at fccache.c:224
>> #8  0x00007ffff7b9feaa in IA__FcDirCacheLoad (dir=<optimized out>,
>>     config=config@entry=0x603040, cache_file=cache_file@entry=0x0)
>>     at fccache.c:738
>> #9  0x00007ffff7ba88a2 in IA__FcDirCacheRead (
>>     dir=dir@entry=0x607040 "/home/behdad/.fonts", force=force@entry=0,
>>     config=config@entry=0x603040) at fcdir.c:477
>> #10 0x00007ffff7ba3e9b in FcConfigAddDirList (config=config@entry=0x603040,
>>     set=set@entry=FcSetSystem, dirSet=0x603150) at fccfg.c:380
>> #11 0x00007ffff7ba3f4b in IA__FcConfigBuildFonts (
>>     config=config@entry=0x603040) at fccfg.c:413
>> #12 0x00007ffff7bad536 in FcInitLoadOwnConfigAndFonts (config=0x603040,
>>     config@entry=0x0) at fcinit.c:163
>> #13 0x00007ffff7bad567 in IA__FcInitLoadConfigAndFonts () at fcinit.c:174
>> #14 0x00007ffff7ba16e7 in FcConfigEnsure () at fccfg.c:46
>> The cache is due for a rewrite, though I have no idea where to start or who
>> should do it.
>> b
> --
> behdad

Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux