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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ fontconfig mailing list fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
