Gary Wright
11/6/2007 9:21:00 PM
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