Re: FW: [RFC] A more general timeout specification

[Joe Korty <joe.korty@ccur.com>]

On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:

> You still didn't explain what's the point in choosing
> different clock sources for a _timeout_.

Well, if CLOCK_REALTIME is set forward by a minute,
timers & timeout specified against that clock will expire
a minute earlier than expected.  That doesn't happen with
CLOCK_MONOTONIC.  Applications should have the ability
to select what they want to happen in this case (ie,
whether the timeout/timer has to happen at a particular
wall-clock time, say 2pm, or if the interval aspects of
the timer/timeout are more important).  Applications
get this if they have the ability to specify the clock
their timer or timeout is specified against.

Also ..... (I am going off the deep end here) .....

The purpose of CLOCK_REALTIME is to track wall clock time.
That means it can be speed up, slowed down, or even be
force-fed a new time to make it match.

The purpose of CLOCK_MONOTONIC is to provide an even,
unchanging progression of advancing time. That is, any two
intervals on this time-line of the same measured length
actually represent, as close as possible, the same length
of time.

CLOCK_MONOTONIC should get adjustments only to bring its
frequency back into line (but currently gets more than this
in Linux).  CLOCK_REALTIME should and does get adjustments
for frequency and then gets further, temporary speedups
or slowdown to bring its absolute value back into line.

Note that there is no need for the two clocks to track each
other in any way, as Linux currently goes to lengths to do.

I know Linux does not implement the above definition
of CLOCK_MONOTONIC; however, I would like an interface
where when, if the day comes time is properly handled,
applications can take advantage of it.

Joe