[Vm-dev] Millisecond clock wraparound

Andreas Raab andreas.raab at gmx.de
Sat Oct 20 03:16:26 UTC 2007


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

Time class>>neverWrappingMSecsClock
	^(self totalSeconds * 1000) + (self millisecondsClock \\ 1000)

Cheers,
   - Andreas

> 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