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. > That looks like then watching the directory and update the cache on > demand may be a solution for this issue though, is it too complicated? 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. > Once all sub directories proceeded, reading the directory seems to be > a workaround. this way is still simple and somewhat better and in fact > the test case works but not perfect. Yeah, something along those lines should work. b > On Tue, Oct 1, 2013 at 4:49 AM, Behdad Esfahbod <behdad@xxxxxxxxxx> wrote: >> On 13-09-29 11:54 PM, Akira TAGOH wrote: >>> Hi, >>> >>> I think this may be a long standing issue and worked around with >>> waiting for a few sec after updating the cache. but I've got a report >>> and still reproducible and finally tracked it down and created 100% >>> reproducible test case by having a logic to get rid of that >>> conditional state. >>> >>> Let me explain how it happens first. fc-cache reads the directory to >>> update the directory cache. as you may know this affects reading the >>> sub-directories to find out fonts. >>> If one is installing a new font while updating and finished reading >>> the sub-directories on it. it won't updates the cache even if a >>> directory is created/removed/renamed. and the cache is created without >>> a directory where being installed a new font and won't be updated so >>> that the cache's timestamp is newer than it. >>> >>> We may need to watch the changes on the directory while updating >>> though, I just want to discuss the possible and the simple solution on >>> this here. >> >> What about this: >> >> - When starting to create a new cache file, note the timestamp, >> >> - When the new cache file is written (right before renaming it to its final >> name) set its timestamp to the timestamp noted above, >> >> - After writing the cache, retry from the start, check again whether the >> cache needs updating. >> >> WDYT? >> >>> Thanks, >>> >>> https://bugs.freedesktop.org/show_bug.cgi?id=69845 >>> >> >> -- >> behdad >> http://behdad.org/ > > > -- behdad http://behdad.org/ _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
