mån 2012-12-03 klockan 09:07 -0700 skrev Alex Rousskov:
> Yes. IIRC, it has been broken before my AsyncCall changes to the main
> loop.
The sawActivity code is from the AsyncCall merge in rev 8812.
> > This will poll non-comm event loops until they are completely idle
> > having nothing to do.
>
> Yes, and that breaks the weight API. The "exhaust all AsyncCalls"
> approach is still needed but we should honor the weight API and stop
> processing timed events sooner if needed.
It breaks not only the weight API but also the limitation to not
schedule timed events added after the current loop started.
> I was going to agree with that wholeheartedly, but then I thought about
> signals. If we visit each non-waiting engine once, then we will only
> process signals once per main loop step. Is that OK?
Not 100% OK, but not too bad. Causes max 1 seconds delay of processing
signals, and the only signals I know of which is not comm related (and
also have comm events) are squid -k signals.
> I think we can still do that provided the
> AsyncEngine::timeTillNextEvent() API discussed below is adjusted to
> allow us to skip the waiting engine completely: If the call returns a
> "check me again ASAP" AsyncEngine::EVENT_ASAP value, the main loop will
> skip the waiting engine. Only the signal engine will return such ASAP
> values.
If this is implemented reasonably lightweight in each event engine.
> I am worried that this will result in 50% or more zero-delay select(2)
> calls for nearly all Squids because there is usually some AsyncCall
> activity per I/O loop (but possibly no timed-events).
So need to make sure AsyncCall is drained last in RunOnce.
Is it sufficient to call dispatchCalls() or do one need to loop over it
until no activity remains?
> And as the code
> migrates from zero-delay timed events to AsyncCalls, the situation will
> become worse. That does not sound like a good fix because it is not
> clear (to me) what kind of side effects this will have on performance.
I don't see how this makes a difference.
AsyncCalls is fired at least twice per comm loop today, before and after
comm.
Regards
Henrik
Received on Mon Dec 03 2012 - 21:02:02 MST
This archive was generated by hypermail 2.2.0 : Tue Dec 04 2012 - 12:00:05 MST