Philip Martin wrote:
> Philip Martin writes:
>> Julian Foad writes:
>>> Flushing after the 1st, 2nd, 4th, 8th, ... log entry provides a crude
>>> approximation to the desired semantics which is more like "don't delay
>>> the first result more than a small fraction of a second, and don't
>>> delay the next few results much more than that either". In other
>>> words, the user's requirement is more about time delays. I wonder if
>>> we could implement something closer to what the user really wants.
>>
>> apr_time_now() is not free so we don't want to call it on every
>> revision, but we could call it before every extra flush. How about no
>> more than one extra flush every 500ms:
+1
> Occassionally the system time will jump because somebody sets the system
> clock. If the system clock were to jump forwards there might be a flush
> that would have been avoided without the jump. If the system clock were
> to jump backwards there may be no extra flushes.
That's good enough fallback behaviour IMO.
- Julian
Received on 2015-03-16 18:51:27 CET