On 2/10/2013 12:59 p.m., Alex Rousskov wrote:
On 09/12/2013 10:48 AM, Alex Rousskov wrote:
The only potentially bad side effect of this change I can think of is
that some events will be scheduled and fired a few microseconds before
they are due (instead of a few microseconds after they are due). I hope
that would not break any existing Squid code. If it does, we can adjust
EventSchedule to round up and, hence, fire all events at or after their
deadline.
I am still concerned about this, even though I do not know of any
specific cases where firing events a little earlier would break things.
It just feels wrong, and I know that libevent or libev specifically
avoids firing events early. Should we change this before the patch is
committed? Or just keep the code simple[r] until we know a change is needed?
To change this, we would need to introduce a minimum I/O wait time (X),
essentially: If some events will become ready to fire in less than X
milliseconds (but are not yet ready now), Squid would still wait for I/O
at most X milliseconds. I suggest setting X to 0.1 millisecond. Any
better ideas?
Nope. Sounds good.
There is no guarantee for any event that it will be run within the same
millisecond (or even same whole second) than which it was scheduled due
to already queued events or Calls taking up time. So adding an explicit
delay will not hurt (much).
Amos
