Just to keep anyone here that might care about this in the loop, we were able to figure out what was going on.
When using native timers on Linux, you can get both absolute and relative timers, depending on the API you use.
Absolute timers will always fire when the system clock says it is a particular time, no matter what the system clock has done in the mean time. So, if you have a timer that fires every hour on the hour, but the clock changes between two firings, there may be more or less than 60 minutes between firings.
Relative timers will always fire after their specified period, no matter what the system clock has done. If you want something to run every 10 seconds, even if the clock changes out from under you, you want a relative timer.
Looking at the code in UnixSystemSupport and how it is called, it seemed as though all of the Timer class APIs that start with #at: should give you an absolute timer, and all of the Timer class APIs that start with #after: or #every: should give you a relative timer.
However, I was overlooking the guard clause at the top of UnixSystemSupport>>enableTimer:after:every:. If the initialPeriod argument (the #after: argument) is negative or 0, then it sends the other API, resulting in an absolute timer.
Thus, all of the Timer class APIs that start with #every: actually result in an absolute timer, not a relative one like I expected. If I simply change my test script to say Timer after: 1 seconds every: 10 seconds do: ["something"], then I get the behavior I expect.
As an aside, Delay specifies a non-zero initialPeriod, so it ends up using a relative timer, which works as Alan reported earlier in the thread.
Thanks to Dan and Alan from Cincom for working through this with me.
Randy
On Fri, Sep 24, 2010 at 2:08 PM, Randy Coulman
<[hidden email]> wrote:
Someone is looking at it. Thanks for the help, though.
RandyOn Fri, Sep 24, 2010 at 2:07 PM, Alan Knight
<[hidden email]> wrote:
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
--
Randy Coulman
[hidden email]
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Locked
