On 22 Jul 2016, at 07:26, Ben Coman <btc@openInWorld.com> wrote:



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]  :) :)

And I reviewed your code and missed it���


cheers -ben


P.S. A trick to debug delays is to bypass interCycleDelay by at the top of it putting...
    true ifTrue: [^self].