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
