<div dir="ltr"><div>Ok, now that you made a release, I'll go ahead and merge this so we get maximum testing.  I'm also making some more variable-fonts changes and I prefer to merge this first and work on top.</div><div><br></div><div>I'll continue regarding the lock in a separate thread.</div><div><br></div><div>Thanks<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 16, 2017 at 9:10 PM, Akira TAGOH <span dir="ltr"><<a href="mailto:akira@tagoh.org" target="_blank">akira@tagoh.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Speeding up the scanning is really nice but IMHO we can't remove the<br>
lock as long as fontconfig has a possibility to update caches from<br>
multiple processes at the same time. improving the speed of updating<br>
caches may reduces the chance to see the issue, but that's it. in<br>
other words, there are still an opportunity to see it if the condition<br>
is met. in fact, that issue was there since quite a long time ago. but<br>
it bagan to happen these days because of processing the updates of<br>
caches in parallel by the package manager etc. so I don't want to do<br>
that unless we have any idea to detect that breakage before writing or<br>
any way to do update cache safely. otherwise we'll see some wired<br>
issues in the future.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Aug 8, 2017 at 2:30 AM, Behdad Esfahbod <<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>> wrote:<br>
> Hi everyone,<br>
><br>
> I have a proposed patchset speeding up fontconfig scanning by 10x, simply by<br>
> not loading glyphs at all, and trusting fonts having correct cmap:<br>
><br>
>   <a href="https://bugs.freedesktop.org/show_bug.cgi?id=64766#c56" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/<wbr>show_bug.cgi?id=64766#c56</a><br>
><br>
> If no one has comments, I like to merge this and get it out for testing in<br>
> the wild.<br>
><br>
> After this, I think we should fix the relocatable feature to not touch<br>
> mmaped cache files.  Here's my proposed approach:<br>
><br>
>   <a href="https://bugs.freedesktop.org/show_bug.cgi?id=101889#c17" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/<wbr>show_bug.cgi?id=101889#c17</a><br>
><br>
> After that, we should clean up the cache race patches and remove the<br>
> locking.  We should accept that cache updates will always remain racy,<br>
> simply because we don't have or want to use the kinds of synchronization<br>
> primitives that guarantee no race.  With scanning 10x faster this shouldn't<br>
> be a problem in practice.  I like to get back to each process trying to<br>
> update the cache and possibly discarding its result if another process<br>
> already did...<br>
><br>
> Cheers,<br>
><br>
> --<br>
> behdad<br>
> <a href="http://behdad.org/" rel="noreferrer" target="_blank">http://behdad.org/</a><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> Fontconfig mailing list<br>
> <a href="mailto:Fontconfig@lists.freedesktop.org">Fontconfig@lists.freedesktop.<wbr>org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/fontconfig" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/fontconfig</a><br>
><br>
<br>
<br>
<br>
--<br>
</div></div><span class="HOEnZb"><font color="#888888">Akira TAGOH<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">behdad<br><a href="http://behdad.org/" target="_blank">http://behdad.org/</a></div>
</div>