From: Miroslav Lichvar <mlichvar@redhat.com>
Date: Fri, 26 Aug 2011 14:52:00 +0000 (+0200)
Subject: Make scheduling loop detector less sensitive
X-Git-Tag: 1.27-pre1~40
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f1a0cacc5a6e9dbdd0718938531f244acf7f98b8;p=thirdparty%2Fchrony.git

Make scheduling loop detector less sensitive

It could be triggered by delayed name resolving as it adds multiple new
timeouts which can be called in the same dispatching if the DNS responses
are slower than initial delay and sampling separation.

Compare number of dispatched events also with current number of
timeouts.
---

diff --git a/sched.c b/sched.c
index 5ea93f68..ae17783d 100644
--- a/sched.c
+++ b/sched.c
@@ -466,11 +466,12 @@ dispatch_timeouts(struct timeval *now) {
     ++n_done;
 
     /* If more timeouts were handled than there were in the timer queue on
-       start, assume some code is scheduling timeouts with negative delays and
-       abort.  Make the actual limit higher in case the machine is temporarily
-       overloaded and dispatching the handlers takes more time than was delay
-       of a scheduled timeout. */
-    if (n_done > n_entries_on_start * 4) {
+       start and there are now, assume some code is scheduling timeouts with
+       negative delays and abort.  Make the actual limit higher in case the
+       machine is temporarily overloaded and dispatching the handlers takes
+       more time than was delay of a scheduled timeout. */
+    if (n_done > n_timer_queue_entries * 4 &&
+        n_done > n_entries_on_start * 4) {
       LOG_FATAL(LOGF_Scheduler, "Possible infinite loop in scheduling");
     }
   }