Problem with delay waiting (OSSubprocess code) on Pharo 5.0

On 22 Jul 2016, at 07:26, Ben Coman <[hidden email]> wrote:

On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck <[hidden email]> wrote:

On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <[hidden email]> 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

[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].

Hi Mariano,  How are you going with this problem?

On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck

<[hidden email]> wrote:
>
>
> On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman <[hidden email]> wrote:
>>
>>
>>
>> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck
>> <[hidden email]> wrote:
>>>
>>>
>>>
>>> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <[hidden email]> 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
>>
>
>
> Hi Ben. I tried to reproduce it in a couple of ways, trying to simulate what
> I do for real but I failed:
>
> | commandString |
> commandString := 'wkhtmltopdf  --javascript-delay 300  --encoding utf8
> --page-size A4 --image-quality 100  --footer-spacing 10  --header-spacing 10
> --margin-top 10  --header-html "http://google.com" --footer-html
> "http://google.com" "http://pharo.org/" "/tmp/TestPharoExport.pdf"'.
>
> 10 timesRepeat: [
>
> 3 timesRepeat: [
> OSSUnixSubprocess new
> shellCommand: commandString;
> redirectStdout;
> redirectStderr;
> runAndWaitOnExitDo: [ :command :outString :errString |
> Transcript show: errString.
> Transcript show: outString.
> ].
>  ].
> Smalltalk saveSession.
>
> ]
>
> But...I could not yet reproduce it in the real case either....so I will keep
> you informed.
>
>
>>>
>>>
>>>>
>>>>
>>>> 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
>>
> Thanks. That did the trick!