On Wed, Oct 2, 2013 at 3:37 AM, Behdad Esfahbod <behdad@xxxxxxxxxx> 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 _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
