Possible Delay problem on Win*

Andreas Raab raab at isgnw.cs.Uni-Magdeburg.DE
Wed Feb 4 23:42:24 UTC 1998


> I'm beginning to suspect that this is related to uptime.
> Win32 Squeak lops two bits off of GetTickCount(), which
> normally overflows it's unsigned DWORD in 49.7 or so days.

Brian, you're right. After digging a bit more into the code I've found the
problem. In Interpreter>>primitiveMillisecondClock the return value of
ioMSecs() is masked to fit into a Squeak SmallInteger, i.e.

  self ioMSecs bitAnd: 16r1FFFFFFF

However, time wrapping is detected by the code in
Interpreter>>checkForInterrupts as follows:

  now _ self ioMSecs. <- the problem's right here

  now < lastTick ifTrue: [
    "millisecond clock wrapped"
     nextPollTick _ now + (nextPollTick - lastTick).
     nextWakeupTick ~= 0
       ifTrue: [nextWakeupTick _ now + (nextWakeupTick - lastTick)]].
  lastTick _ now.  "used to detect millisecond clock wrapping"

See what's happening? When executing (Delay forMilliseconds: n) the wakeup
time is computed based on the _masked_ ioMSecs from the
primitiveMillsecondClock value. Wrapping however, is detected based on the
raw ioMSecs. So, if the system millisecond clock value is between the
maximum value of primitiveMilliseconds wrapping occurs for wakeup time but
is not detected in the VM.

It's not difficult to fix, but I'm rather happy that we've figured this
out. BTW, this should actually also happen on other systems with longer
uptimes, such as Unix.

Andreas

-- 
Linear algebra is your friend - Trigonometry is your enemy.
+===== Andreas Raab ============= (raab at isg.cs.uni-magdeburg.de) =====+
I Department of Simulation and Graphics      Phone: +49 391 671 8065  I
I University of Magdeburg, Germany           Fax:   +49 391 671 1164  I
+=============< http://isgwww.cs.uni-magdeburg.de/~raab >=============+





More information about the Squeak-dev mailing list