On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <btc@openinworld.com> wrote:
Do you have some test code or a test image I could run to reproduce the problem?
The problem is that I cannot reproduce it immediately. It takes me some days and likely some image save and start again until I reproduce it.
Could you try How about something that invokes
Now I have one thing for you to try. In the move of DelaySchedulerXxx from milliseconds to microseconds, the code for dealing with clock wrap-around was removed, but I wonder if it was also covering clock jitter as a side effect. Could you try again the SpinScheduler but restore this code...
From handletTimerEvent... "Check for clock wrap-around." millisecondNowTick < activeDelayStartTime ifTrue: [ "clock wrapped" self saveResumptionTimes. self restoreResumptionTimes ]. activeDelayStartTime := millisecondNowTick.
From runTimerEventLoop... Time millisecondClockValue < millisecondNowTick ifTrue:[ timingSemaphore signal ]. "retry"
From startup... activeDelayStartTime := Time millisecondClockValue.
OK, I put back the code into the spin scheduler. Then I kept using milisecond one until I finished the changes. Then I saved image and switch to spin one: the image hungs. I cannot even interrupt it. I attach my modifications. Do they look correct?
I confirm that locked my image also. One change of milli to micro was missed at the bottom of runTimeEventLoop... That is... Time millisecondClockValue < microsecondNowTick to... Time microsecondClockValue < microsecondNowTick (just a case of domestic blindness) [1] :) :) cheers -ben [1] http://www.urbandictionary.com/define.php?term=domestic%20blindness P.S. A trick to debug delays is to bypass interCycleDelay by at the top of it putting... true ifTrue: [^self].