<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 26, 2016 at 3:38 AM, L. A. Walsh <span dir="ltr"><<a href="mailto:fonts@tlinx.org" target="_blank">fonts@tlinx.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Generated per dir, yes, but when you choose a directory to<br>
update, isn't the time to update it proportional to the number<br>
of files in that directory?  Using an extreme case as an example,<br>
if you had 10,000 files in that one dir that were all copies<br>
of 1 of the files and if the program knew that -- couldn't it generate<br>
the info needed for 1 file and, at worse, duplicate it 9,999 times, to<br>
avoid the calculation cost for the 9,999 copies (if it "knew" they<br>
were copies?).</blockquote><div><br></div><div>For what to make such copies in the same directory?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  IO race?  Too much I/O for older machines?  Maybe have it<br></blockquote><div><br></div><div>No, the race on updating caches.</div><div>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.</div><div>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.</div><div><br></div><div>-- </div></div><div class="gmail_signature" data-smartmail="gmail_signature">Akira TAGOH</div>
</div></div>