[Cuis-dev] FW: FW: FW: Freezing UI - can't interrupt via Alt+.

[Juan Vuletich]

Hi Jaromir,

On 8/2/2022 7:05 PM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan,
>
> I'd like to share my analysis regarding the dependence of the solution 
> presented in my previous message on the choice of the preemption mode 
> (i.e. whether preempting a process involves an implicit yield like in 
> Cuis/Pharo or without the yield like in Squeak, indicated by 
> #processPreemptionYields value true or false, which is in fact Eliot's 
> improvement over the Blue book applied in Squeak currently).
>
> I wrote:
>
> > [...] the preemption mode is critical in this case so I'll have to 
> figure out how to make this work for Squeak :D Or better yet how to 
> make it independent of the processPreemptionYields setting.
>
> Now I think the behavior *is* supposed to be different for different 
> preemption modes, so there's nothing different to do for Squeak. 
> Compare the following examples:
>
> [1/0] fork.
>
> Processor yield.
>
> [ 10000 factorial ] repeat
>
> [1/0] fork.
>
> [ 10000 factorial. Processor yield ] repeat
>
> In the first example the UI places the [1/0] process in the run queue 
> and continues to execute the #yield which allows the [1/0] process 
> run, encounter the error, open a new UI, place it in the run queue 
> behind the former UI and suspend itself. Then the former UI resumes 
> again and keeps computing factorials in the repeat cycle.
>
> Now comes the crucial point: in Squeak with processPreemptionYields = 
> false the former UI keeps computing factorials and never lets the new 
> UI take over (even when interrupted) and hence no debugger opens, 
> while in Cuis where processPreemptionYields = true the former UI 
> computing the factorials is interrupted from time to time by a higher 
> priority process (time watcher?) which causes the former UI do 
> implicit yield and move to the end of the run queue which allows the 
> new UI do one cycle, open a debugger and just keep the UI responsive.
>

Exactly.

> In my opinion both behaviors are correct and should be expected based 
> on the choice of the preemption mode.
>
> In the second example the #yield inside the repeat loop does 
> explicitly more or less what the implicit yield does when 
> processPreemptionYields = true so the resulting behavior is the same 
> regardless of the preemption mode.
>

Right. In my (just sent) answer to the previous email I also said that 
if the user set #processPreemptionYields = false, they should have their 
reasons.

> One more point: when you wrap both examples in fork, i.e. when you run 
> the examples in a non-UI process the behavior is identical as when 
> they run in the UI; I guess this is important.
>
> [ [1/0] fork.
>
> Processor yield.
>
> [ 10000 factorial] repeat] fork
>
> [ [1/0] fork.
>
> [ 10000 factorial. Processor yield] repeat] fork
>
> Thanks for your time; I'm sure nothing of it is news for you but at 
> least for me looking at it from the UI angle has been an interesting 
> and sometimes surprising exercise :)
>
> Thanks again,
>
> Jaromir
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net
>
>

The truth is that "in theory" there was nothing new, i.e. I already knew 
the specification for the behaviors. But "in practice", many of these 
examples were surprising to me, and they took quite a bit of thought to 
understand them, and to see that they were actually following the 
specification. And then, the important part: To decide if the observed 
(and now understood) behavior is what we want, or if what we expected 
before running the example is what should happen. This triggers the hard 
work, the new insights, and the better code.

Thank you!

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220804/c1621792/attachment-0001.htm>