[HarfBuzz] To HB_NO_MT or not to HB_NO_MT

[Konstantin Ritt]

2015-03-29 0:33 GMT+04:00 Behdad Esfahbod <behdad.esfahbod at gmail.com>:

> On 15-03-28 03:28 PM, Konstantin Ritt wrote:
> > Issue: in a multi-threaded application, there is no possibility to check
> if HB
> > library we're linking to is thread-safe -> we blindly assume it is.
>
> Right.  I think a shared-library version of HB must always be threadsafe,
> and
> if it's not, that's a packaging bug.
>
> The biggest user of no-MT is Firefox, which AFAIU always uses HB from one
> thread and doesn't want to incur the MT cost.
>

The cost is rather minimal. I hope they're using the system-wide HB library
where possible, at least...


> Proposed solution: in case the configure script failed to detect the
> supported
> > atomic primitives, proceed with a warning and expect the build to fail
> if the
> > user didn't provide his own implementation (ie. in config.h or via some
> > external include). This way, we could even get rid of HB_NO_MT path --
> where
> > explicitly required, the user would be able to provide his no-MT
> > implementation (ie. for HB built in a single-threaded application).
> >
> > WDYT?
>
> I would like to say I'm fine with that; however, the single-threaded
> implementation is not exactly trivial, so I don't like to leave it to
> individuals to figure it out.
>
> How about this:
>
> For both warnings in hb-warnings.cc, that is, the MT warning and the
> no-Unicode-funcs warnings, make both into hard errors.  For the former,
> remove
> mentioning HB_NO_MT, and instead suggest defining correct platform flags.
> For
> the latter, suggest including hb-ucdn into their build.
>
> WDYT?
>

Sounds good to me.
I think a configure option like --threading=no, with BIG FAT warning in its
description, would make sense (here is where configure script will define
HB_NO_MT).

\note The no-Unicode-funcs warning is in hb-unicode.cc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20150329/f035663d/attachment.html>