[7.7.1] Native timers and clock changes

No one seems to have answered this, but no, your understanding of how it works seems to agree with mine, but I don't observe the same symptoms.

So, if I start an image on Ubuntu, which is as I understand it, Debian-based, and do a TimerSystem useNativeInterfaceIfAvailable, save the image, restart, do a 10 seconds wait surrounded by statements that print the current time to the Transcript, and then while it's delaying, set the time back by 30 seconds, it still takes what feels more like 10 seconds, and the end time it prints out is well before the start time.

At 12:23 PM 2010-09-14, Randy Coulman wrote:

We're in the process of bringing our application forward from 7.6 to 7.7.1.  One of the things we want to take advantage of is the new native timer support.  We're running on Debian Linux.

Our application runs such that it is the only thing on the screen.  We have a clock, and give our users the ability to change the system time.  In 7.6, we had to force an application restart after changing the system time, because the delays/timers in the system didn't react well to the time change. 

This problem was supposed to be addressed by the native timers, but I'm finding that this is not true.  We have a number of background threads running (and waiting), and as far as I can tell, these stop running for a minute if I set the clock back by a minute.  Setting the clock ahead seems to work alright (though I'd guess that some processes are waking up too early).

I know that the classic timers are the default, but we turn on native timers when building our base image, so there has been an image restart after changing the default timer facility.

Am I misunderstanding something about how the native timers are supposed to work?

Thanks,
Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

OK. Then I'm suspicious that it is a question of timer semantics. I believe with Unix timers you can have both absolute time based and duration based, and I suspect that every:do: is getting the one you're not expecting. At least, I do see the same thing you do with that script, but different semantics if I do

20 timesRepeat: [
   10 seconds wait.
    Transcript cr; show: Timestamp now printString].

At 04:20 PM 2010-09-24, Randy Coulman wrote:

I ended up opening a support case on this, but I'll keep up the discussion here as well.

In my workspace, I did something like this (in an image with native timers turned on):

timer := Timer every: 10 seconds do: [Timestamp now out].

Then I messed with the clock under the hood using this:

sudo hwclock --utc --set --date="<new time here>"; sudo hwclock --hctosys

Moving forward, I get hiccups in the output; moving back, I get no output until the clock catches up with what the time was when I set it back.

Randy

On Fri, Sep 24, 2010 at 1:10 PM, Alan Knight <[hidden email]> wrote:

No one seems to have answered this, but no, your understanding of how it works seems to agree with mine, but I don't observe the same symptoms.

So, if I start an image on Ubuntu, which is as I understand it, Debian-based, and do a TimerSystem useNativeInterfaceIfAvailable, save the image, restart, do a 10 seconds wait surrounded by statements that print the current time to the Transcript, and then while it's delaying, set the time back by 30 seconds, it still takes what feels more like 10 seconds, and the end time it prints out is well before the start time.

At 12:23 PM 2010-09-14, Randy Coulman wrote:

We're in the process of bringing our application forward from 7.6 to 7.7.1.  One of the things we want to take advantage of is the new native timer support.  We're running on Debian Linux.

Our application runs such that it is the only thing on the screen.  We have a clock, and give our users the ability to change the system time.  In 7.6, we had to force an application restart after changing the system time, because the delays/timers in the system didn't react well to the time change. 

This problem was supposed to be addressed by the native timers, but I'm finding that this is not true.  We have a number of background threads running (and waiting), and as far as I can tell, these stop running for a minute if I set the clock back by a minute.  Setting the clock ahead seems to work alright (though I'd guess that some processes are waking up too early).

I know that the classic timers are the default, but we turn on native timers when building our base image, so there has been an image restart after changing the default timer facility.

Am I misunderstanding something about how the native timers are supposed to work?

Thanks,

Randy

--

Randy Coulman

[hidden email]

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

--
Randy Coulman
[hidden email]

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

OK, but it sounds like this is an issue that either the native timers on Unix behave differently than I would have guessed for recurring timers, or that one of the Timer APIs is giving the wrong sort of timer (or at least an unexpected sort) but that the native timer support as a whole does seem to be able to produce either relative or absolute timers. And if you've got a case with support, then someone who understands these things better than I do should be looking into the details.

At 05:00 PM 2010-09-24, Randy Coulman wrote:

I also tried the experiment with Timer>>at:every:do: which is supposed to produce an absolute timer, and that didn't work either.

Randy

On Fri, Sep 24, 2010 at 1:56 PM, Alan Knight <[hidden email]> wrote:

OK. Then I'm suspicious that it is a question of timer semantics. I believe with Unix timers you can have both absolute time based and duration based, and I suspect that every:do: is getting the one you're not expecting. At least, I do see the same thing you do with that script, but different semantics if I do

20 timesRepeat: [

   10 seconds wait.

    Transcript cr; show: Timestamp now printString].

At 04:20 PM 2010-09-24, Randy Coulman wrote:

I ended up opening a support case on this, but I'll keep up the discussion here as well.

In my workspace, I did something like this (in an image with native timers turned on):

timer := Timer every: 10 seconds do: [Timestamp now out].

Then I messed with the clock under the hood using this:

sudo hwclock --utc --set --date="<new time here>"; sudo hwclock --hctosys

Moving forward, I get hiccups in the output; moving back, I get no output until the clock catches up with what the time was when I set it back.

Randy

On Fri, Sep 24, 2010 at 1:10 PM, Alan Knight <[hidden email]> wrote:

No one seems to have answered this, but no, your understanding of how it works seems to agree with mine, but I don't observe the same symptoms.

So, if I start an image on Ubuntu, which is as I understand it, Debian-based, and do a TimerSystem useNativeInterfaceIfAvailable, save the image, restart, do a 10 seconds wait surrounded by statements that print the current time to the Transcript, and then while it's delaying, set the time back by 30 seconds, it still takes what feels more like 10 seconds, and the end time it prints out is well before the start time.

At 12:23 PM 2010-09-14, Randy Coulman wrote:

We're in the process of bringing our application forward from 7.6 to 7.7.1.  One of the things we want to take advantage of is the new native timer support.  We're running on Debian Linux.

Our application runs such that it is the only thing on the screen.  We have a clock, and give our users the ability to change the system time.  In 7.6, we had to force an application restart after changing the system time, because the delays/timers in the system didn't react well to the time change. 

This problem was supposed to be addressed by the native timers, but I'm finding that this is not true.  We have a number of background threads running (and waiting), and as far as I can tell, these stop running for a minute if I set the clock back by a minute.  Setting the clock ahead seems to work alright (though I'd guess that some processes are waking up too early).

I know that the classic timers are the default, but we turn on native timers when building our base image, so there has been an image restart after changing the default timer facility.

Am I misunderstanding something about how the native timers are supposed to work?

Thanks,

Randy

--

Randy Coulman

[hidden email]

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

--

Randy Coulman

[hidden email]

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

--
Randy Coulman
[hidden email]

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk