Here the two lines of code, from Delay>>activate, which making me feel bad:
TimingSemaphore initSignals. Delay primSignal: TimingSemaphore atMilliseconds: resumptionTime.
Things can go wild, if VM will signal previously scheduled timer semaphore between first line and second line.
The more appropriate code would be:
Delay primSignal: nil atMilliseconds: 0. "reset VM timer, so there is no chance that TimingSemaphore can be signaled in between" TimingSemaphore initSignals. Delay primSignal: TimingSemaphore atMilliseconds: resumptionTime.
Without it, there are chance that delay can be signaled prematurely, and also a TimingSemaphore will have an excessive signals after VM signal it again.
I not sure if this is possible at all. VM checks for interrupts at each real send. A primitive , which is in #primSignal:atMilliseconds: is not real send, so maybe its ok here, but i would not put much trust into it. The code should be written in a way, that it impossible to break it regardless on how often VM checks for interrupts.
A more reliable, would be is to change primitive and reset signals counter of installed semaphore. This will ensure atomicity. So, a primitive would behave as following: - reset semaphore signals - schedule semaphore signal at given millisecond clock value
squeak-dev@lists.squeakfoundation.org