Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

[linux@horizon.com]

> - "timer API" vs "timeout API": I got absolutely no acknowlegement that 
> this might be a little confusing and in consequence "process timer" may be 
> a better name.

I have to disagree.  Once you grasp the desirability of having two kinds
of timers, one optimized for the case where it does expire, and one
optimized for the case where it is aborted or rescheduled before its
expiration time, the timer/timeout terminology seems quite intuitive
to me.

In particular, knowing that there are these two kinds of timers, and
they are called "timer" and "timeout", it's immediately obvious to me
which is which.  I have no idea which one a "process timer" is.

The word "timeout" is already understood to refer to an error-recovery
mechanism.  The common and desired case is that a timeout does not occur,
but rather the device responds, the packet is acknowledged, or what
have you.

Also, a common use case is that a timeout is continuously active, but its
expiration time keeps getting postponed.  And great accuracy in timing is
not required; if the timeout expires 10% late, very little harm is done.

Finally, timeouts are always relative to some triggering event, not
absolute.

Given this, a specialized timer implementation that optimizes timer
scheduling at the expense of timer expiration makes all sorts of sense.


Note that the network stack can make good use of both kinds.  Timeouts
for all the usual network timeouts, but high-resolution timers are very
desirable for transmission rate control.