<div dir="ltr">I think you are talking about the case for FAT. we do wait for 2 seconds to exit because the resolution of mtime on FAT is it. though it doesn't help for running many processes to update caches because it isn't a singleton process and other process can access caches and the targeted directories/fonts during updating.<div>fc-cache might be multi-threading but I'm not sure if writing caches is the thread-safety nor worth doing so. and if we do, doing it as a single process like demonizing may be better, to avoid complication.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 2:30 PM, Keith Packard <span dir="ltr"><<a href="mailto:keithp@keithp.com" target="_blank">keithp@keithp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Akira TAGOH <<a href="mailto:akira@tagoh.org">akira@tagoh.org</a>> writes:<br>
<br>
> The former one was what I took measures for that. I expect it works as long<br>
> as the process is done within the most accurate time.<br>
<br>
</span>Is there some place we could add a suitable delay to ensure that file<br>
system without sub-section timestamps could get reliable results using<br>
inexpensive timestamp checking, rather than expensive file scanning? I<br>
recall placing a 'sleep' in the cache generation code, but presumably<br>
that's insufficient?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
-keith<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Akira TAGOH</div>
</div>