Hi Dave,
Thanks for answering. Inline.
On 3/6/2017 10:50 PM, David T. Lewis wrote:
In the VM, the millisecond clock wraps within the 32 bit integer range:
#define MillisecondClockMask 0x1FFFFFFF
In the Cuis image, Delay class>>handleTimerEvent does this:
nextTick := nextTick min: SmallInteger maxVal.
On a 64-bit Spur image, SmallInteger maxVal is 16rFFFFFFFFFFFFFFF, but on a 32-bit image it is 16r3FFFFFFF.
Could that be it?
I wasn't aware of that, and had assumed that millisecond timer would use the whole SmallInteger range. This might introduce a bug, that would only appear at timer rollover, i.e. about 6 days after image startup. I'll fix this. Thanks.
But this is a completely separated issue. The problem we saw, the semaphore never being signaled if deadline is in the past, happens immediately after image startup.
I don't really know how to test in Squeak. As you say, Squeak is now using the microsecond clock in #handleTimerEvent. I do not see anything in primitiveSignalAtMilliseconds that would behave any differently on a 64 bit versus 32 bit image or VM, but I do not know how to test to be sure.
Dave
Well, what follows is a way to test VM behavior. Tested in Cuis, but should be trivial to reproduce in Squeak, as it is a VM issue. I Cuis add (copied from Squeak):
!Time class methodsFor: 'general inquiries' stamp: 'jmv 3/7/2017 08:58:12'! utcMicrosecondClock "Answer the UTC microseconds since the Smalltalk epoch (January 1st 1901, the start of the 20th century). The value is derived from the Posix epoch with a constant offset corresponding to elapsed microseconds between the two epochs according to RFC 868." <primitive: 240> ^0! !
!Delay class methodsFor: 'primitives' stamp: 'jmv 3/7/2017 08:57:45'! primSignal: aSemaphore atUTCMicroseconds: anInteger "Signal the semaphore when the UTC microsecond clock reaches the value of the second argument. Fail if the first argument is neither a Semaphore nor nil, or if the second argument is not an integer. Essential. See Object documentation whatIsAPrimitive." <primitive: 242> ^self primitiveFailed! !
Then, in a Workspace, try the following 4 doits:
s _ Semaphore new. Delay primSignal: s atUTCMicroseconds: Time utcMicrosecondClock + 10. s wait. 'Ok' print.
s _ Semaphore new. Delay primSignal: s atMilliseconds: Time millisecondClockValue + 10. s wait. 'Ok' print.
s _ Semaphore new. Delay primSignal: s atUTCMicroseconds: Time utcMicrosecondClock - 10. s wait. 'Ok' print.
s _ Semaphore new. Delay primSignal: s atMilliseconds: Time millisecondClockValue - 10. s wait. 'Not OK at all' print.
On Spur32, all 4 finish immediately. On Spur64, the first 3 also finish immediately, but the fourth freezes the image. The difference in behavior between Spur32 and Spur64 (on Linux) is indeed there.
Ok. Also tried Squeak (note that instead of #millisecondClockValue in Squeak it is #primMillisecondClock) :
s _ Semaphore new. Delay primSignal: s atUTCMicroseconds: Time utcMicrosecondClock + 10. s wait. 'Ok'.
s _ Semaphore new. Delay primSignal: s atMilliseconds: Time primMillisecondClock + 10. s wait. 'Ok'.
s _ Semaphore new. Delay primSignal: s atUTCMicroseconds: Time utcMicrosecondClock - 10. s wait. 'Ok'.
s _ Semaphore new. Delay primSignal: s atMilliseconds: Time primMillisecondClock - 10. s wait. 'Not OK at all'.
Exactly the same behavior.
I just took a look at static void primitiveSignalAtMilliseconds(void) in https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/src/vm/... The only thing I see is that msecs is an usqInt and deltaMsecs is an sqInt. But I'm not good enough at gcc subtleties to say if this matters at all. I mean, it looks as if 'if (deltaMsecs < 0) {' was true on Spur64 and false on Spur32... Or maybe the difference is in the handling of nextWakeupUsecs ...
In any case, it looks like deadlines in the past are not supported (as code assumes they are because of rollover...)
Thanks,