[Cuis-dev] Strange behavior with stepping

[Juan Vuletich]

Gerald,

On 8/21/2021 3:00 PM, Gerald Klix via Cuis-dev wrote:
> Juan,
>
> Sorry for being a spoilsport. 

:) This is the best way to improve the system. Collective understanding. 
I love it!

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

Maybe we'd make them atomic. Critical sections and such.

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

I'm not sure this is the best solution. Coding app code using 
#whenUIinSafeState: may be way more difficult, as you no longer can 
assume your code runs in sequence. If possible, by all means I prefer 
securing the framework rather than making the app coder life harder.

> You have to know that the UI uses
> threads/processes even if your code doesn't.
> Thanks to Phil for pointing this out.

Let's keep thinking and discussing.

Thanks,

> 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
>>>>
>>>>
>>
>>


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich