[Fontconfig] fontConfig design problems? Implications of a single "fcConfig"

Phil Race Phil.Race at Sun.COM
Tue Aug 28 13:41:19 PDT 2007


Hello,

Can anyone comment on the following :

There is a global variable declared in fcint.h that holds the default configuration :

extern FcPrivate FcConfig       *_fcConfig;

it is implicitly initialised by calling FcInit()
and implicitly destroyed by calling FcFini().

What this apparently means is that its rarely safe to call FcFini(),
ie except when you control the overall binary executable.
Since if two modules in the same executable try to use fontconfig,
neither of which is aware of the other,  and one "completes" its usage
of Fontconfig, and diligently tries to free resources, then it may
be exposing the other client to problems up to and including a SEGV.

I am also wondering if this can really be safe in a MT-world?

Aside from the FcFini() case, is concurrent access to the
global fontconfig expected to be safe?

If not surely most of the functions that utilise the default
should be deprecated and everyone needs to use their own copy
and synchronize?

ie you need to call

     FcConfig *config = FcConfigCreate();
     FcConfigParseAndLoad (config, 0, FcTrue);
     FcConfigBuildFonts(config);


and use it all for fns that take a FcConfig doing your own
higher level synchronization.

Finally http://fontconfig.org/fontconfig-devel/r2256.html

has :
FcBool FcConfigParseAndLoad(FcConfig *config, const FcChar8 *file);

but the source has :
FcBool
FcConfigParseAndLoad (FcConfig      *config,
                       const FcChar8 *name,
                       FcBool        complain)

fortunately the implications of failing to initialise this arg is
probably limited but the docs should be updated!

-phil.


More information about the Fontconfig mailing list