[Fontconfig] commit (branch): read and write cache files.

[Keith Packard]

On Mon, 2005-07-25 at 14:39 -0400, Patrick Lam wrote:
> Keith Packard wrote:
> > I was thinking we'd continue to use per-directory caches unless you
> > don't think that will work. The reason here is that each user can add
> > directories to the set, and having only a global cache means that
> > everyone would have a ~/.fonts.cache-2 file. Right now, the local caches
> > are significantly more expensive to use as many additional stat(2) calls
> > are needed to validate the cache.
> 
> I think that per-directory caches will work once I implement banked
> references to mmaped objects, e.g. right now we have
> 
> typedef struct _FcValueListPtr {
>     FcStorage               storage;
>     union {
>         int                 stat;
>         struct _FcValueList *dyn;
>     } u;
> } FcValueListPtr;
> 
> and after my next change we'll have
> 
> typedef struct _FcStaticPtr {
> 	int bank;
> 	int offset;
> } FcStaticPtr;
> 
> typedef struct _FcValueListPtr {
>     FcStorage               storage;
>     union {
>         FcStaticPtr         stat;
>         struct _FcValueList *dyn;
>     } u;
> } FcValueListPtr;
> 
> I wonder if we should manually pack the FcStaticPtr into, say, 24 bits
> for offset and 8 bits for bank.  Or if we should wonder about that for
> now.  The banked data structures enable per-directory caches.

If that would limit the number of directories to 256, that would be
bad...

However, what you might consider is making the special bank value of '0'
mean a pointer with other bank values being offsets. That would reduce
the size of the FcValueListPtr back to 8 bytes on 32-bit machines:

typedef struct _FcValueListPtr {
	int	bank;
	union {
		int stat;
		struct _FcValueList *dyn;
	} u;
} FcValueListPtr;

#define FC_BANK_DYNAMIC		0

> 
> The only remaining issue is that FcObjectPtr is now an int, and we want
> to keep it that way.  We can probably do something clever there, maybe
> again the 24/8 split or something.

I fear weird structures like this. If there aren't a lot of them in
writable memory, then a simpler representation will cause fewer problems
in the future.

> 
> > If we need a single global cache, it would need to live in /var
> > somewhere, which is something of a pain as there isn't strong concensus
> > on what /var should look like these days. A quick read through the LSB
> > might provide some suggestions.
> 
> Hopefully we can avoid the single global cache.

Right. That leaves us with the same file structure we have today. There
have been requests for us to *permit* externally stored cache files for
read-only directories (generally on shared Windows partitions). We can
consider how to manage that after we have per-directory caches working
again.

Thanks for all of your hard work.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050725/bd94b930/attachment.pgp