On Sun, 17 Jan 2016 21:56:53 +0100 Raimund Steger <rs@xxxxxxxx> wrote: > On Thu, 14 Jan 2016 22:39:37 -0800 > Keith Packard <keithp@xxxxxxxxxx> wrote: > > > Akira TAGOH <akira@xxxxxxxxx> writes: > > > > > As I mentioned in other mail, it was needed to avoid the races. to get > > > rid of it completely, the logic of the cache updates may needs to be > > > changed because keeping the directory information into the memory a > > > long time causes that issue easily when recursively traversing > > > directories. > > > > As long as the timestamp written to the cache is the directory change > > time when the scanning starts, then applications starting after that > > will re-scan the directory if it was changed while the first application > > was scanning. I guess I don't see how this (which is what I think the > > code does) could cause a race? > > Wouldn't it need to be the timestamp that was used in the very first call to FcCacheTimeValid? But it's not implemented like that, is it? Ah scratch that, seems to be OK after all, there's a stat in FcDirCacheScan. -- Worringer Str 31 Duesseldorf 40211 DE home: <rs@xxxxxxxx> +49-179-2981632 icq 16845346 work: <rs@xxxxxxxxxxxxxxx> _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
