[Cuis-dev] Strange behavior with stepping

[Gerald Klix]

Juan,

Sorry for being a spoilsport. If I think about Heap>>#first
and Heap>>#privateRemoveAt:, the first one might execute
atomically, the second one, indirectly invoked by #removeFirst
or #remove:, is IHMO too complicated to be atomic.

Until now I did not proofread the CuisBook, but I have
the dark suspicion, that one might find that stepping
stuff without proper guarding.

In general I would like to see this stepping setup-methods
wrapped in sends of #whenUIinSafeState:. Hilaire's mistake
is made too easy. You have to know that the UI uses
threads/processes even if your code doesn't.
Thanks to Phil for pointing this out.


Best Regards,

Gerald


On 8/21/21 7:39 PM, Juan Vuletich via Cuis-dev wrote:
> Hi Folks,
> 
> Nice catch, Gerald. On top of that, #removeFirst could have the same 
> problem. I just pushed to GitHub your code, but also fixing the call to 
> #removeFirst.
> 
> Hilaire, please try with the latest from GitHub. I believe Gerald is 
> right, and this could fix the problem you found.
> 
> Thanks!
> 
> On 8/21/2021 10:04 AM, Gerald Klix via Cuis-dev wrote:
>> Hi Hilaire,
>>
>> I only did a short static analysis
>> (a fancy word for looking at the code
>> and scratching your head).
>>
>> IHMO there's a race condition:
>>
>> WorldMorph>>#runLocalStepMethods
>>
>>     | stepMessage |
>>     [ stepList notEmpty and:
>>            [ stepList first scheduledTime <= nowTime ]]
>>         whileTrue: [
>>             stepMessage _ stepList first.
>>
>>
>> This piece of code looks at the scheduleTime of the
>> heap's first element then actually retrieves
>> the first element.
>> While this happens the heap in stepList may
>> be changed by adding or removing elements.
>>
>> Please try the attached method and tell me if it helps.
>>
>> @Juan: Even if my change does not fix Hilaire's problem
>> the method should still be changed.
>>
>>
>> HTH,
>>
>> Gerald
>>
>>
>> On 8/21/21 1:14 PM, Hilaire Fernandes via Cuis-dev wrote:
>>> Hi,
>>>
>>> In DrGeo there is this user interaction to let the user easily merges 
>>> two points: the user moves one point over another one to merge with, 
>>> then holds for 1500 milliseconds for the merging operation to take 
>>> place.
>>>
>>> It is done with stepping:
>>>
>>> restartMouseStillDownHandle         self startStepping: 
>>> #processMouseStillDown             in: 1500             stepTime: 1]
>>>
>>> The problem is the mouseStillDown message is called immediately not 
>>> after 1500 milliseconds.
>>>
>>> Looking at step code below, is the at: argument right? Tried with 
>>> Time millisecondClockValue (as coded with Pharo), the effect is the 
>>> same:
>>>
>>> startStepping: aSelector in: millisecs stepTime: stepTime     "Start 
>>> stepping the receiver"     self world ifNotNil: [ :w |         w 
>>> startStepping: self             at: Time localMillisecondClock + 
>>> millisecs             selector: aSelector             stepTime: 
>>> stepTime]
>>>
>>> Any clue?
>>>
>>> Thanks, best
>>>
>>>
> 
>