On Nov 6, 2007, at 3:48 PM, MenTaLguY wrote:

> On Wed, 7 Nov 2007 05:23:46 +0900, Gary Wright <gwtmp01 / mac.com>  
> wrote:
>> Ruby's sleep actually is a request to the thread scheduler to
>> stop the current thread until the system clock has reached
>> (now + delay).  So if you move the clock backwards, it will take
>> that much longer to reach (now + delay).  If you move the clock
>> forwards then the thread becomes runnable immediately.
>
> I think this is arguably a bug in the scheduler, but it is not
> easy to remedy in a portable way.

I'd be curious to even see a non-portable way to do this.  I just
think that the Unix/Posix semantics of time/timers basically
assumes monotonically increasing ticks.

If you want a process to detect decreasing time and/or skewed
ticks you are going to have to compare the clock to other
clocks (i.e. you are going to have to re-invent NTP).

I guess you could detect decreasing time easily enough but I don't
see how you can do it other than by polling and comparing timestamps.

To go back to the original posters situation, I don't think that
clock skew and/or discontinuities can be dealt with at the application
level.  It has to be solved at a higher/operational level.

Gary Wright