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

From: Roman Zippel
Date: Thu Sep 01 2005 - 10:19:53 EST


Hi,

On Thu, 1 Sep 2005, Joe Korty wrote:

> 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 just rather suggests that the pthread API is broken as usual.
(No other possible user was mentioned so far.)

> 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.

So setup a timer that goes off at that time and interrupts the operation.
There is no need to overload the operation itself with an overly complex
timeout specification.

> 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.

That would make a rather useless CLOCK_MONOTONIC. The basic problem is
that it would be very hard to specify the time without exactly knowing
it's frequency, the larger the time difference the larger the time skew
would be compared to CLOCK_REALTIME and without an atomic clock in your
computer you have no way of knowing which one is "real".
So in practice it's easier to advance CLOCK_MONOTONIC/CLOCK_REALTIME
equally and only apply time jumps to CLOCK_REALTIME.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/