[Fontconfig] mmap-ed caches + patch
mclasen at redhat.com
Wed Sep 28 02:19:48 EST 2005
On Tue, 2005-09-27 at 18:12 +0200, Lubos Lunak wrote:
> On Tuesday 27 September 2005 17:47, Patrick Lam wrote:
> > Lubos Lunak wrote:
> > > However, when I tested the 2.3.90 release yesterday, I was originally
> > > disappointed to see it performed noticeably worse than the last stable
> > > version. Short version: Please apply the attached patch. Longer version:
> > > The problem turned out to be directories that contain files that
> > > fontconfig doesn't seem to use yet it analyses them (.pcf.gz files). If a
> > > directory contains only .pcf.gz files and has no subdirectories, then the
> > > code that the patch removes will not write a cache file, yet the return
> > > FcTrue means the directory has been successfully cached. However if you
> > > look in
> > > FcCacheReadDirs() you can see that if it can't use the cache file it will
> > > call FcDirScanConfig(). So I suggest the attached patch which will write
> > > a more or less empty cache file even in such directories.
> > I'm not sure that this patch will not cause problems. I think that I
> > want to generate a zero-length file in such a case, without a header at
> > all. But I'm a bit confused: when I run fc-cache in a directory with
> > only pcf.gz files, fc-cache *does* generate a fonts.cache-2 file for me.
> > Why is this different for you?
> Maybe that directory you have has also a subdirectory? In the attached file
> there's output of 'ls' in /usr/X11R6/lib/X11/fonts/latin2/misc and also the
> output of 'fc-cache -f -v'. You can see that it says 0 fonts, 0 dirs, which
> AFAICS exactly matches the condition my patches removes.
> > > And, actually, it seems I've just found another problem :(. If I run
> > > Konqueror, run 'fc-cache -f' and go back to Konqueror, it crashes quite
> > > soon. Guessing from strace of fc-cache, where I cannot see any call to
> > > unlink(), and from the calls to ftruncate() I assume that the new cache
> > > file contents are written directly in the same file instead of unlinking
> > > the old file first, and fontconfig doesn't survive that. As I don't
> > > understand the code that much I cannot confirm this theory for sure,
> > > which also means no patch for this, sorry :).
> > Which cache file are you talking about? $HOME/.fonts.cache-2, or a
> > directory cache? (Are you running fc-cache as root?)
> Any cache file I'd say (and yes, I ran fc-cache as root). AFAIK if you
> truncate a file that's mmap-ed, any access to the no longer existing part of
> the file results in bad things. I don't know the structure of the cache file,
> it seems to me it can be built in several steps for different architectures,
> but I'd expect that the code can't cope with the data simply changing under
> its hands, and unless the format specifically prevents that I'd expect that
> to happen. Would there be any problem if you simply unlinked the old file
> before writing the new one?
Thats what we do with other mmapped caches in GTK+, atomically replace
them by writing the new cache to a tmp file, and then moving it in
More information about the Fontconfig