Bump...I also need this resolved.

This also occurs with select having a timeout...which I believe is
ruby's definition of sleep anyway.

--
Posted via http://www.ruby-forum.com/.

On Nov 6, 2007, at 9:44 AM, Robert Williams wrote:
> Bump...I also need this resolved.
>
> This also occurs with select having a timeout...which I believe is
> ruby's definition of sleep anyway.
>

What do you mean by 'also'? Your first posting was
about a timeout with select.

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.

This might also explain why your C version works since it is
probably calling the sleep/nanosleep system call rather than
communicating with some process based/green thread scheduler.

Gary Wright

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.

-mental

FYI was a thread about this back in March:
http://blade.nagaokaut.ac.jp/cgi-bin...by-talk/241281

-rr-

On 11/6/07, MenTaLguY <mental@rydia.net> 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.
>
> -mental
>
>
>

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

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

On Nov 6, 2007, at 4:08 PM, Gary Wright wrote:
> On Nov 6, 2007, at 3:48 PM, MenTaLguY wrote:
>> 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.

Maybe I spoke to quickly. I guess it depends on the types
of timers provided by the OS. You would have to use something
other than a real-time clock timer. I'm not sure what semantics
the various Posix timers and/or OS-specific timers have with
respect to the system clock changing.

Gary Wright

My application is a server based scheduler...
Schedules are scheduled for a calendar year.
My admin user may test the schedule by changing the system time time and
time again.

Anyway, my work around was to have a c program send a IPC message to the
scheduler every second. At which point the scheduler would watch for
unusual time deviations and handle things accordingly...i.e. clean up a
sleeping thread.

In other scenarios, as mentioned in the ruby rails thread (which I
bumbed). Daylight savings, or a move, may require a system clock change
by the user.
It would be better to handle this case cleanly with out requireing the
user shut down all ruby daemons which may make use of select in
trheads....or require them to reboot.

my 2 cents.
Cheers!
--
Posted via http://www.ruby-forum.com/.

On Nov 6, 2007, at 4:17 PM, Rak Rok wrote:

> FYI was a thread about this back in March:
> http://blade.nagaokaut.ac.jp/cgi-bin...by-talk/241281

In that thread, Tomas Pospisek suggested switching timeofday()
to use a POSIX monotonic clock but his solution would have
screwed up Time.now since it would no longer be returning wall clock
time.

It seems like there there are at least two use cases that tend to be
obscured in this conversation:

delay by a time interval # i.e. a stopwatch, not a wall clock
delay until a time is reached # i.e. a wall clock, not a stopwatch

The problem is that many systems don't have an OS supported stopwatch,
only an OS supported wall clock.

In addition, MRI Ruby treats the wall clock as a stopwatch and so you
would have to refactor things if you had both types of clocks available.
You can't just switch everything to use the stopwatch.

I suspect there might be lots of hidden problems in application code
if you changed sleep(), for example, to behave like a stopwatch. What
if the application computes an interval based on the time of day and
then calls sleep(interval)? In that case, the application *wants*
a wall-clock model and not a stopwatch model.

Gary Wright

On Nov 6, 2007, at 4:39 PM, Robert Williams wrote:
> Anyway, my work around was to have a c program send a IPC message
> to the
> scheduler every second. At which point the scheduler would watch for
> unusual time deviations and handle things accordingly...i.e. clean
> up a
> sleeping thread.

Yikes! You have a scheduling system that spans an entire calendar
year that needs 1-second granularity? The fact that you even mention
a 'calendar' indicates to me that you want events to be synched to
wall-clock time anyway--so it sounds like a contradiction to want
to ignore wall-clock changes. Most likely though, I'm not aware
of the entire context you are working in.

FYI, in reading the Ruby code during this thread I think I noticed
that if there is only a single thread that sleep(x) actually uses
select() directly to wait for the elapsed time. I guess my point
is that if you really want a process to send you an IPC message
every second you can do that with Ruby also--just don't start any
other threads.

Gary Wright

I don't want to waste a lot time describing my application. I have a
work around and it meets my customers' needs.

Back to the timeout issue. The interesting thing is that this problem
does not occur in the main thread. Earle's example at the top
demonstrates this. So the main thread clock acts like a stop watch and
the spawned thread acts like a wall clock waiting for the time. It
seems the should both behave the same way.

Cheers,
Robert
--
Posted via http://www.ruby-forum.com/.