Fontconfig - Aug 2007 - fontConfig design problems? Implications of a single "fcConfig"

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.