On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck < marianop...@gmail.com> wrote:
> > > On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <b...@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].
