[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] squeak.cog.v3 CI tests fail randomly (#436)

[Nicolas Cellier]

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>