[Fontconfig] Race condition on updating cache
Akira TAGOH
akira at tagoh.org
Tue Oct 1 12:07:51 PDT 2013
On Wed, Oct 2, 2013 at 3:37 AM, Behdad Esfahbod <behdad at behdad.org> wrote:
>
> On 13-10-01 07:09 AM, Akira TAGOH wrote:
> > just tried. but seems not help because generating cache in test case
> > is finished too quickly. so checksum in FcCache and mtime is the same
> > for all. then it considered no-updates.
>
> So, IIUC, you are saying that our file timestamps are just too coarse to be
> useful... I believe that. I know that's why fc-cache used to sleep for one
> seconds. I don't know if that's still the case on Linux.
Right. that said I suppose it may be useful only when it is the
singleton process, in fact this issue happened with sleep one second.
at least waiting for one sec just before exiting didn't help. it might
be better moving between reading the directory and writing the cache
perhaps. so it might catches up updates on reading caches. let me try
that later.
Though one concern would be the penalty on missing/outdated cache is
heavier than current one because this weight has to be moved into the
library rather than fc-cache itself.
> Not necessarily too complicated, but too heavy. The total number of file
> watches per user is quite limited, and having every fontconfig-using process
> watch 100 directories doesn't quite work. Lets not go there. In GNOME we
> have one process monitor and signal others whenever font changes happen.
Aha. true. I just wonder if the kind of fc-cached may helps then.
--
Akira TAGOH
More information about the Fontconfig
mailing list