[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] squeak.cog.v3 CI tests fail randomly (#436)
Nicolas Cellier
notifications at github.com
Sun Oct 27 16:15:50 UTC 2019
Ah, I see that the roll-over case was handled at image side already, at the end of `handleTimerEvent`
...snip...
"Since we have processed all outstanding requests, reset the timing semaphore so
that only new work will wake us up again. Do this RIGHT BEFORE setting the next
wakeup call from the VM because it is only signaled once so we mustn't miss it."
TimingSemaphore initSignals.
Delay primSignal: TimingSemaphore atMilliseconds: nextTick.
"This last test is necessary for the obscure case that the msecs clock rolls over
after nowTick has been computed (unlikely but not impossible). In this case we'd
wait for MillisecondClockMask msecs (roughly six days) or until another delay gets
scheduled (which may not be any time soon). In any case, since handling the
condition is easy, let's just deal with it"
Time millisecondClockValue < nowTick ifTrue:[TimingSemaphore signal]. "retry"
I added the protection to prevent `long` overflow in `ioRelinquishProcessorForMicroseconds`.
The protection is not strictly necessary after https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/b80dd63c2aa1517b186099b9669a89e4385772cb.
However, I see that the `SuspendedDelays` sorting by `resumptionTime` will be BAD after a roll-over. Those greater than limit/2 should come before those less than limit/2! This should be handled at the end of `handleTimerEvent`. These delays might never get signalled...
This does not explain why CI still fails...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/436#issuecomment-546709747
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20191027/fe16dc6f/attachment.html>
More information about the Vm-dev
mailing list