[Fontconfig] mmaping FcInit

[Lars Knoll]

On Saturday 26 March 2005 12:49, Owen Taylor wrote:
> On Sat, 2005-03-26 at 10:10 +0100, Lars Knoll wrote:
> > On Friday 25 March 2005 22:25, Owen Taylor wrote:
> > > On Fri, 2005-03-25 at 01:53 -0500, Patrick Lam wrote:
> > > > BTW, Owen's suggested struct:
> > > > struct FcPattern {
> > > >     int refcount;
> > > >     FcPatternStorage storage; /* dynamic, static */
> > > >
> > > >     union {
> > > >       FcPatternDynamic *dynamic;
> > > >       FcPatternStatic *static;
> > > >     } u;
> > > >   };
> > > >
> > > > still seems to be a struct, and thus requiring mallocness and a
> > > > pointer.
> > >
> > > The point of my suggestion is that we need a single *public* structure
> > > for:
> > >
> > >   - Patterns retrieved from the database of fonts on disk
> > >   - Patterns created on the fly through the FcPattern API
> > >
> > > But that public structure can be small, lightweight, and created on
> > > the fly.
> >
> > Do you really? FcPattern is a completely opaque type. For patterns on the
> > disk, you can just return a pointer to them. All that should be needed is
> > one bitflag in the pattern structure itself marking it a begin readonly,
> > and using the same data structure for dynamic patterns.
> >
> > This requires using the same endianness and packing for dynamic and
> > static patterns and thus makes building up dynamic pattern a little more
> > complex, but I don't think the overhead would be noticable (and the code
> > is needed for the cache building anyway). The advantage would the that
> > retrieving of properties from the pattern could use the same code.
>
> My thought that it would be hard to create a structure that both worked
> on disk and was suitable for efficient implementation operations like
> FcPatternAdd/FcPatternDel. The fundamental problem I see is that
> FcPatternAdd requires allocating more storage, but you can't call
> realloc on the FcPattern pointer.

Hmmm... true. The need to allocate more space spoils the whole possibility of 
static and dynamic patterns using exactly the same structure. I still think 
that you could probably avoid the overhead of allocating anything for static 
patterns with a pattern as below:

struct FcPattern {
	int Type; // Dynamic or Static
};

struct FcPatternStatic {
	FcPattern p;
	FcPatternData data; 
};

struct FcPatternDynamic {
	FcPattern p;
	int refcount;
	FcPatternData *data;
};

That way you have almost the same data structure for both types. The only 
difference would be the way to get a pointer to the pattern data. 

> I could be missing some tricky way to set things up, however.
>
> Changing things so that a static FcPattern was only one memory block
> would be easier, though if you don't reference count static patterns,
> you may have trouble with font database changes,

Won't font database changes require mmaping the new cache file? In that case 
you probably need a global refcount for all patterns in the mmaped file, so 
you know when nothing references the old cache file anymore.

Cheers,
Lars