<div dir="ltr">Just FYI: <a href="https://github.com/KonstantinRitt/harfbuzz/commit/b22902c699093be6629d7ece871a1ad759fdc557">https://github.com/KonstantinRitt/harfbuzz/commit/b22902c699093be6629d7ece871a1ad759fdc557</a></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Regards,<br>Konstantin</div></div>
<br><div class="gmail_quote">2015-03-29 4:13 GMT+04:00 Konstantin Ritt <span dir="ltr"><<a href="mailto:ritt.ks@gmail.com" target="_blank">ritt.ks@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-03-29 0:33 GMT+04:00 Behdad Esfahbod <span dir="ltr"><<a href="mailto:behdad.esfahbod@gmail.com" target="_blank">behdad.esfahbod@gmail.com</a>></span>:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><span>On 15-03-28 03:28 PM, Konstantin Ritt wrote:<br></span></span><span class=""><span>> Issue: in a multi-threaded application, there is no possibility to check if HB<br>
> library we're linking to is thread-safe -> we blindly assume it is.<br>
<br>
</span>Right.  I think a shared-library version of HB must always be threadsafe, and<br>
if it's not, that's a packaging bug.<br>
<br>
The biggest user of no-MT is Firefox, which AFAIU always uses HB from one<br>
thread and doesn't want to incur the MT cost.<br></span></blockquote><div><br></div><div>The cost is rather minimal. I hope they're using the system-wide HB library where possible, at least...</div><span class=""><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> Proposed solution: in case the configure script failed to detect the supported<br>
> atomic primitives, proceed with a warning and expect the build to fail if the<br>
> user didn't provide his own implementation (ie. in config.h or via some<br>
> external include). This way, we could even get rid of HB_NO_MT path -- where<br>
> explicitly required, the user would be able to provide his no-MT<br>
> implementation (ie. for HB built in a single-threaded application).<br>
><br>
> WDYT?<br>
<br>
</span>I would like to say I'm fine with that; however, the single-threaded<br>
implementation is not exactly trivial, so I don't like to leave it to<br>
individuals to figure it out.<br>
<br>
How about this:<br>
<br>
For both warnings in hb-warnings.cc, that is, the MT warning and the<br>
no-Unicode-funcs warnings, make both into hard errors.  For the former, remove<br>
mentioning HB_NO_MT, and instead suggest defining correct platform flags.  For<br>
the latter, suggest including hb-ucdn into their build.<br>
<br>
WDYT?<br></blockquote><div><br></div></span><div>Sounds good to me.</div><div>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).</div><div><br></div><div>\note The no-Unicode-funcs warning is in hb-unicode.cc </div></div><br></div></div>
</blockquote></div><br></div>