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@rowledge.org; http://www.rowledge.org/tim Manual Writer's Creed: Garbage in, gospel out.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===