|
|
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
--
Best regards,
Igor Stasenko AKA sig.
|
Locked
