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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.