[Fontconfig] Re: [patch]: mmapping FontConfig data structures

[Patrick Lam]

Keith Packard wrote:
> Ok, now that I'm a bit more awake, here's what I'd *like* to see in an
> mmap-based patch for fontconfig:
> 
>  1)  The mmap-able files are a *replacement* for the existing
>      cache files.
> 
>  2)  Automatic discovery of new fonts still works, which
>      means timestamp checking of font directories at
>      application startup.
> 
>  3)  mmap'able files are address-independent
> 
>  4)  mmap'able files are architecture-independent

It so happens that I have also modified fontconfig to make most internal
data structures offset-based rather than address-based, and it would be
relatively straightforward.  However, this causes a large diff file, and
can productively be done in another diff if you'd be willing to commit
this one, so that we separate the two sets of major changes from each other.

I'm not currently familiar with the existing 'fc-cache' program, but
will look into it.  I also need to think a bit about how to do automatic
discovery of new fonts, but it ought to be possible with a bit of work.

> 3) is necessary if these files are to replace the existing cache as
> being unable to map the cache files would be
> catastrophic in the absense of another level of caching.

Going to an offset-based representation would make these files
address-independent.  This is straightforward but tedious.

> 4) could be solved by making fc-cache store multiple
> versions of the cache information in the same file with a small header
> that provides a mapping into that data.
> Applications would read the header and mmap the appropriate section of
> the file.

Yes, this is quite easy to do with that hint.

> I assume that these changes would require a redesign of most of the
> fontconfig internal data structures to switch from pointers to offsets.
> I believe the necessary data structures are all hidden from the
> application so that this should be possible.

As with my earlier diff from two months back, the only
externally-visible change would be FcPattern* -> FcPatternIdx.

How would you like to proceed?  I could equally well cook up a patch
which changes FcPattern* -> FcPatternIdx, etc and you could commit that
first.  This would be a large but straightforward patch, easy to review;
from that version, I could fix the current patch to use offsets instead.
Once we have the functionality in the current patch, then I could look
into automatic updating and subsuming the current cache files.

pat