642254134e
No starvation of timeout signals -------------------------------- Add several timeouts < 1ms to the stress test and check that timeout handling doesn't become significantly unfair (starvation) in this situation where some timeouts trigger nmuch faster than they get handled. Rate limiting for timeout handling in timer ------------------------------------------- Ensure that the timer does not handle timeouts again within 1000 microseconds after the last handling of timeouts. This makes denial of service attacks harder. This commit does not limit the rate of timeout signals handled inside the timer but it causes the timer to do it less often. If a client continuously installs a very small timeout at the timer it still causes a signal to be submitted to the timer each time and some extra CPU time to be spent in the internal handling method. But only every 1000 microseconds this internal handling causes user timeouts to trigger. If we would want to limit also the call of the internal handling method to ensure that CPU time is spent beside the RPCs only every 1000 microseconds, things would get more complex. For instance, on NOVA Time_source::schedule_timeout(0) must be called each time a new timeout gets installed and becomes head of the scheduling queue. We cannot simply overwrite the already running timeout with the new one. Ref #2490 |
||
|---|---|---|
| .. | ||
| app | ||
| drivers | ||
| init | ||
| lib | ||
| server | ||
| test | ||