[Fontconfig] mmap-ed caches + patch

[Matthias Clasen]

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
place.

Matthias