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

Wed Aug 10 05:24:10 PDT 2022

Hi Juan,

I very much like your simplifying the code opening a debugger :)

I'm still just skimming the surface of the UI implementation but I'd like to ask a few questions:

(1) why is there Object >> #runningWorld
- wouldn't sending `UISupervisor runningWorld` instead of `true runningWorld` be sufficient e.g. in Debugger >> #openWindowLabel:usePreDebugWindow:preDebugMessage:?

(2) Why not define UISupervisor >> runningWorld via #animatedUIOf: to avoid code duplicity?

UISupervisor >> runningWorld
                "
                UISupervisor runningWorld
                [ UISupervisor runningWorld print ] fork
                "
                ^self animatedUIOf: Processor activeProcess

(3) I understand your intention when you lowered the former UI process's priority in #spawnNewMorphicProcessFor: by one; I believe it was in response to this example:

[1/0] fork.
5 seconds asDelay wait.
self error: 'error'

I've been wondering whether it's still relevant after your most recent changes - and unfortunately it seems that it is: changing the former UI process's priority back to the active priority will cause redraw glitches (e.g. Transcript background color in Dark mode won't display properly).

However, there seems to be a very similar redraw blip *despite* the lower priority tweak when running e.g.
[1/0] fork.
[1/0] fork
... the Transcript window won't get redrawn correctly in the Dark mode: it won't change its background color properly. It puzzles me why the Transcript window is the only one affected.

What I'm trying to figure out is: if the computation carried out by this former UI process involves references to Processor activePriority the priority-lowering tweak may change the semantics of a computation involving forking processes at different relative priorities (in other words changing the priority of the process in the middle of the computation by an *unrelated* "outsider" process feels dangerous); just a theoretical idea though, unfortunately I don't have any practical example or any further suggestion; I'll return to this later after some more educating myself :)

About the processPreemptionYields flag:

> I think it would be important to understand why would someone want #processPreemptionYields = false. Their reasons for requesting a process to never yield to others of same priority (even if some higher process wakes up in between) may also mean they don't want new UI processes to be started so lightly.

Here's Eliot's explanation why he chose #processPreemptionYields = false over the previous functionality: https://forum.world.st/about-signal-tp5109735p5109862.html

My understanding is he simply thinks #processPreemptionYields = true produces an inconsistent/erroneous behavior in the sense that unless a process *explicitly* yields control it should stay in control (unless preempted by a higher priority process in which case it should get back control once the higher priority process gives up control, i.e. stay at the front of the run queue).

In case of Squeak (which is on #processPreemptionYields = false) each world cycle does contain an explicit yield anyway so opening each debugger in a new UI doesn't seem to clash with this stricter cooperative-within-priorities scheduling approach imho :)

A while ago I asked Marcel about the preemption modes and the answer was (roughly) that #processPreemptionYields = false offers more predictability (understandably) plus something about thread-safe-ness of Morphic structures (which is still way beyond my skills level).

Is there a reason why you'd prefer #processPreemptionYields = true or is it just for historic reasons? ("why fix something that works" type of situation? :) )

Thanks again very much for discussing these issues!

Best regards,
Jaromir

--

Jaromír Matas

mail at jaromir.net

________________________________
From: Juan Vuletich <juan at cuis.st>
Sent: Thursday, August 4, 2022 2:46:17 PM
To: Discussion of Cuis Smalltalk <cuis-dev at lists.cuis.st>
Cc: Jaromir Matas <mail at jaromir.net>
Subject: Re: [Cuis-dev] FW: FW: FW: Freezing UI - can't interrupt via Alt+.

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<mailto: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/20220810/c0ec9d5b/attachment-0001.htm>