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
