On Sun, 13 Mar 2016 13:40:41 -0700 Behdad Esfahbod <behdad@xxxxxxxxxx> wrote: > [...] > There are four usecases we need to consider: > > - Normal Linux / other Unix-like. We can assume high-precision > timestamps are available and take care of stuff, > > - Linux / Unix-like system with network file system. Any issues there > with your proposed patch? NFSv3 spec has nanoseconds, but I think server support is optional. I'll do some research what kind of support currently is out there. The implementations I'm using here seem to support it. Even if not, there might be little choice, as the stat penalty is most severe with NFS and 2.11 behavior is more acceptable IMHO. > - Linux / Unix-like system with FAT or other low-precision timestamp file > system. Do we care much about that? I believe we've fixed bugs for those > systems before. I just am not sure how much we care about small races > there. FAT (where FcIsFsMtimeBroken returns true) was always scanned completely even before f44bfad2, in FcDirChecksum. This is independent. Other embedded file systems might lack nanoseconds true, but the question is how contested is the cache on such systems. I don't recall a lot of bugreports either, so the 2.11 state might just be fine as it is. > - Windows. I'm fine with leaving some known races there alone. GetFileAttributesEx, which fontconfig uses, has 100 nanosecond resolution if the filesystem supports it (NTFS should). But only seconds are used by fontconfig right now. I'll look into that. Raimund -- Worringer Str 31 Duesseldorf 40211 DE home: rs@xxxxxxxx +49-179-2981632 icq 16845346 work: rs@xxxxxxxxxxxxxxx _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
