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
Received on Wed Oct 02 2013 - 00:08:46 MDT
This archive was generated by hypermail 2.2.0 : Thu Oct 31 2013 - 12:00:17 MDT