timeout(9): new flag: TIMEOUT_SCHEDULED, new statistic: tos_scheduled

This flag is set whenever a timeout is put on the wheel and cleared upon
(a) running, (b) deletion, and (c) readdition.  It serves two purposes:

1. Facilitate distinguishing scheduled and rescheduled timeouts.  When a
   timeout is put on the wheel it is "scheduled" for a later softclock().
   If this happens two or more times it is also said to be "rescheduled".
   The tos_rescheduled value thus indicates how many distant timeouts
   have been cascaded into a lower wheel level.

2. Eliminate false late timeouts.  A timeout is not late if it is due
   before softclock() has had a chance to schedule it.  To track this we
   need additional state, hence a new flag.

rprocter@ raises some interesting questions.  Some answers:

 - This interface is not stable and name changes are possible at a
   later date.

 - Although rescheduling timeouts is a side effect of the underlying
   implementation, I don't forsee us using anything but a timeout wheel
   in the future.  Other data structures are too slow in practice, so
   I doubt that the concept of a rescheduled timeout will be irrelevant
   any time soon.

 - I think the development utility of gathering these sorts of statistics
   is high.  Watching the distribution of timeouts under a given workflow
   is informative.

ok visa@

0 files changed, 0 insertions, 0 deletions