https://bugs.openldap.org/show_bug.cgi?id=9878
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- In terms of master/2.7, we should probably revert 07e79471f94037cc60b860a740f99a8016c14270 to not have syncrepl stuck in ldap_result() for no reason (ITS#9534 carries no hints as to why this wait should be needed if our event loop implementation itself isn't buggy) and stabilise the semantics of the runqueue interval to mean "run this again in <interval> seconds after last schedule or at the earliest opportunity afterwards".
This lets us avoid the current busy-loop for dispatcher thread with interval == 0. A trivial change in the implementation of our dispatcher makes the duration of each cycle from infinity to O(n^2) steps if we have n non-deferred tasks in the queue. More invasive changes of the API might be required to make this O(n) or faster.
Alternatively, we could make interval == 0 mean "do not reschedule automatically" and make it the task's responsibility to decide when the next call is appropriate. This would avoid several hacks in back_mdb/etc. where a ridiculously large interval is chosen to avoid being rescheduled.