Diego Santa Cruz wrote: >> -----Original Message----- >> From: Behdad Esfahbod [mailto:behdad.esfahbod@xxxxxxxxx] On Behalf Of >> Behdad Esfahbod > >> I've committed all but the last two. > > Glad to know that I can contribute a bit to open source projects :-) > >>> - fontconfig-2.6.0-cache-insert.patch >>> when a cache is rebuilt and inserted into the linked list of >>> caches the stat data should be brought up to date once the cache is >>> written to disk, otherwise the next time the cache is verified it >> will >>> be reloaded even if the in memory version matches the on disk cache. >> Wouldn't we be better off freeing the cache we have and loading it from >> disk? >> That way we can mmap it. Right? >> > > Yeah, that would be even better. I admit that I stopped halfway through, but when I saw that the cache files in our setting are at most a few KBytes then I moved to some more urgent stuff. However using the mmap is an additional step on top of this patch (or a modified version of it), since if the cache size is less than the minimum mmap size there is no point in re-reading it from disk and this patch is still useful. Right. I'll give it a try. But I'm short in time for testing this. So if you can do that, would be even better. >>> - fontconfig-2.6.0-Win32-atomic-replace.patch >>> under Windows an mmap'ed file cannot be removed so >>> FcAtomicReplaceOrig() fails if the old cache is larger than >>> FC_CACHE_MIN_MMAP and is still open (either by the same or other >> app); >>> this patch workarounds this issue by renaming the old cache file if >> the >>> unlink fails. Note that with this patch fontconfig may leave .OLD >> cache >>> files around, but I do not have a better idea on how to overcome >> this. >> >> This should be fine. What if the OLD file is still in use? Then we >> still >> fail. How about trying OLD, OLD2, OLD3? OLD files will still be use >> if >> there's an application mapping them still. For example, even with your >> patch, >> the second time you install fonts, it may fail. >> > > Yep, I agree that this is only a partial solution that works in some cases only. In our app it does work since after reloading the fontconfig caches we force pango to drop all its fontconfig references as well, so the OLD file is never mapped when we need to write a new one. I'm not comfortable using too many OLDx files since that may leave quite a bit of old files around in the cache directory. Unfortunately I have not come up with any better way of doing this. Is there a way in Windows to at least mark a file for deletion once nobody has it mapped nor opened ? That would be a way of not leaving useless files behind. What do you think would be a sane number of OLDx versions to try before giving up? That's a question for win32 people. AFAIC, something like 3 or 4 is fine. behdad > Best, > > Diego > > PS: sorry if the lines in this message are too long, I'm really fighting with MS Outlook to be more Internet friendly but somehow it sometimes insists in not formatting Internet messages to the specified width. _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
