fontConfig design problems? Implications of a single "fcConfig"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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);

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


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

but the source has :
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!

Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux