mån 2012-12-03 klockan 22:25 -0700 skrev Alex Rousskov:
> I disagree with this logic. Yes, sawActivity approach supports long
> chains, but they are not the loop's fault! If some chain is too long,
> the bug is in that chain's code and should be fixed there. If it cannot
> be fixed there, then the chain is not "too long", but Squid is just
> being asked to do "too much".
The event engines we talk about here is
SignalEngine
EventScheduler
StoreEngine
Of these only possibly StoreEngine may need repeated work.
SignalEngine is happy if it gets polled every now and then at low
frequency.
EventScheduler do not want to be polled more than once per loop.
StoreEngine is about store callbacks. In the past this should not be
invoked too often per loop.
> It is difficult to resolve this disagreement. I argue that the
> sawActivity loop should stay because breaking call chains by I/O
> callbacks will lead to bugs, but I cannot show you any specific bug it
> will cause. You argue that some chains might be so long that they will
> starve I/O, but you cannot show any specific "too long" chain (after the
> heavy event handling bug is fixed).
store I/O is known to have done this in the past.
> Perhaps we can agree to let the sleeping dog lie? The bug you needed to
> fix was with the heavy events handling. My patch or your next patch fix
> that bug. Let's not remove the sawActivity loop until its removal
> becomes the best solution for some other bug. We can discuss the loop's
> pros and cons in the context of that specific bug then.
Ok.
I would probably go for both pathes. Solves different aspects of the
event loop timings.
My patch fixes the delay calculation, both end result and readability,
and enabling removal of sawActivity. But it does not fix the comm
starvation issue without removal of sawActivity. Today the comm loop
delay is often too short in current code.
Your patch addresses sawActivity and heavy events. If sawActivity loop
is removed in future then your patch have no effect but still makes code
more readable.
Regards
Henrik
Received on Tue Dec 04 2012 - 08:47:39 MST
This archive was generated by hypermail 2.2.0 : Tue Dec 04 2012 - 12:00:05 MST