Re: Streamlining fontconfig scanning
Behdad Esfahbod <[email protected]>
| Newsgroups | gmane.comp.fonts.fontconfig |
|---|---|
| Message-ID | <CAF63+7V6p-DfW_QNp3zA0gD52L5qdNCXnFd5jEEN4pUB+SFEbQ@mail.gmail.com> |
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. I'll continue regarding the lock in a separate thread. Thanks On Wed, Aug 16, 2017 at 9:10 PM, Akira TAGOH <[email protected]> wrote: > Speeding up the scanning is really nice but IMHO we can't remove the > lock as long as fontconfig has a possibility to update caches from > multiple processes at the same time. improving the speed of updating > caches may reduces the chance to see the issue, but that's it. in > other words, there are still an opportunity to see it if the condition > is met. in fact, that issue was there since quite a long time ago. but > it bagan to happen these days because of processing the updates of > caches in parallel by the package manager etc. so I don't want to do > that unless we have any idea to detect that breakage before writing or > any way to do update cache safely. otherwise we'll see some wired > issues in the future. > > On Tue, Aug 8, 2017 at 2:30 AM, Behdad Esfahbod <[email protected]> wrote: > > Hi everyone, > > > > I have a proposed patchset speeding up fontconfig scanning by 10x, > simply by > > not loading glyphs at all, and trusting fonts having correct cmap: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=64766#c56 > > > > If no one has comments, I like to merge this and get it out for testing > in > > the wild. > > > > After this, I think we should fix the relocatable feature to not touch > > mmaped cache files. Here's my proposed approach: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=101889#c17 > > > > After that, we should clean up the cache race patches and remove the > > locking. We should accept that cache updates will always remain racy, > > simply because we don't have or want to use the kinds of synchronization > > primitives that guarantee no race. With scanning 10x faster this > shouldn't > > be a problem in practice. I like to get back to each process trying to > > update the cache and possibly discarding its result if another process > > already did... > > > > Cheers, > > > > -- > > behdad > > http://behdad.org/ > > > > _______________________________________________ > > Fontconfig mailing list > > [email protected] > > https://lists.freedesktop.org/mailman/listinfo/fontconfig > > > > > > -- > Akira TAGOH > -- behdad http://behdad.org/ _______________________________________________ Fontconfig mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/fontconfig