[Vm-dev] Millisecond clock wraparound

Chris Muller asqueaker at gmail.com
Sat Oct 20 02:26:01 UTC 2007


Is this issue currently solveable from the image?  i.e., is it
possible to simulate a millisecond clock that never wraps?

On 10/19/07, John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
>
> That is the short answer.
>
> primitiveMillisecondClock
>         "Return the value of the millisecond clock as an integer. Note that
> the millisecond clock wraps around periodically. On some platforms it
> can wrap daily. The range is limited to SmallInteger maxVal / 2 to
> allow delays of up to that length without overflowing a SmallInteger."
>
>         self pop: 1 thenPush: (self integerObjectOf: (self ioMSecs bitAnd:
> MillisecondClockMask)).
>
>
>         MillisecondClockMask := 16r1FFFFFFF.
>
>
> Note the comment about how
>
> ioMSecs
>
> might return values that wrap daily....
>
>  From the historical perspective Dan discovered a number of issues
> with wrapping when OS-9 ish came out and macintosh computers were
> able to run
> his weather station software for 24 days straight without crashing
> which was the magic point when the pre os-x operating system
> millisecond clock timer rolled over.
> Of course that might still apply today, how many days is a billion
> milliseconds?  12.427 so days?  so rollover is in 6 & 1/4 days?
>
>
>
> On Oct 19, 2007, at 1:45 PM, tim Rowledge wrote:
>
> >
> > On 19-Oct-07, at 1:17 PM, Keith Hodges wrote:
> >
> >>
> >> In the 3.10 date and time code It seems I wrongly assumed that the
> >> millisecond clock would wrap-around at SmallInteger maxVal.
> >>
> >> Is there a way to know this exactly for every platform?
> > In the current VM code the timer is wrapped at SmallInteger
> > maxVal //2 because it was a simple hack fix to setting long delays
> > - ie if the max tick value was 1B and the max delay interval 1B
> > then it wouldn't overflow. I proposed a much better fix ages ago
> > that I think was incorporated.
> > It's not a platform issue so far as I know.
> >
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Manual Writer's Creed:  Garbage in, gospel out.
> >
> >
>
> --
> ========================================================================
> ===
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ========================================================================
> ===
>
>
>


More information about the Vm-dev mailing list