[Fontconfig-bugs] [Bug 101889] Make fontconfig cache relocatable

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=101889

--- Comment #16 from Behdad Esfahbod <freedesktop at behdad.org> ---
(In reply to Behdad Esfahbod from comment #15)
> (In reply to Alexander Larsson from comment #13)
> > Yes, we could do it lazily, true. However, I don't understand what you mean
> > about sharing with others.
> 
> When the mapped file is not modified, the backing memory is shared across
> processes.  They are copy-on-write.  If we can completely avoid changing is
> even better.  I have a scheme in mind that does that.
> 
> 
> > Here is what i imagine:
> > 
> > [Shared mmaped cache data]
> > ...
> > FontName="TheFont"
> > FileName=offset 0
> > ...
> > FontName="OtherFont"
> > FileName=offset 1
> > ...
> > FileNameTable
> > [offset 0]
> > [offset 12]
> > FileNameStrings
> > "TheFont.ttf\0OtherFont.ttf\0"
> > 
> > This would be readonly and shared by all clients.
> > To go from a cache element to a filename you would normally
> > go from offset in FileNameTable to offset in FileNameStrings, all shared by
> > everyone. However, in the case where the cache is loaded in a non-canonical
> > location, you'd allocate an in-memory (non-shared) FileNameTable and
> > FileNameStrings array, which would would rewrite and use instead.
> > 
> > Such a setup could be lazy, either doing everything the first time you get a
> > filename, or it could allocate filenames one-by-one lazily. (Although then
> > you create a lot of small allocations instead of a single large one.

Yes, I have something very similar to that in mind.  It's doable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20170802/52487571/attachment.html>