On Sat, Nov 26, 2016 at 3:38 AM, L. A. Walsh <fonts@xxxxxxxxx> wrote:
Generated per dir, yes, but when you choose a directory to
update, isn't the time to update it proportional to the number
of files in that directory? Using an extreme case as an example,
if you had 10,000 files in that one dir that were all copies
of 1 of the files and if the program knew that -- couldn't it generate
the info needed for 1 file and, at worse, duplicate it 9,999 times, to
avoid the calculation cost for the 9,999 copies (if it "knew" they
were copies?).
For what to make such copies in the same directory?
IO race? Too much I/O for older machines? Maybe have it
No, the race on updating caches.
As I said, the cache is generated per dirs and the parent cache is also updated. when caches needs to be updated, that would means fonts were added/updated/deleted or directories containing a font were added/updated/deleted. what if some processes is updating the same cache? what if some processes are updating caches for additions during updating caches for deletion? and so on. FWIW this isn't a paranoid. is examples actually happened in the past.
Though fc-cache itself doesn't prevent to do so so far. you could do it with knowing such risks if you want. I did the workaround as much as I can. at least I'm not aware of it on the packaging system possibly runs the scriptlet in parallel but I'm not sure if it is perfect.
--
Akira TAGOH
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
