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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
