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

Jaromir Matas mail at jaromir.net
Tue Aug 2 15:05:43 PDT 2022 

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.

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.

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

From: Jaromir Matas via Cuis-dev<mailto:cuis-dev at lists.cuis.st>
Sent: Monday, August 1, 2022 14:38
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>; juan at cuis.st<mailto:juan at cuis.st>
Cc: Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] FW: FW: FW: Freezing UI - can't interrupt via Alt+.

Hi Juan,

In our previous discussion we discussed a few examples:

[1/0] fork.
[ 10000 factorial. 5 seconds asDelay wait ] repeat

This one represents a situation where the UI is blocked and we (mostly you indeed) modified the code to create a new UI to open the debugger for the [1/0] process request while the old UI is idly waiting.

[1/0] fork.
[ 10000 factorial. Processor yield ] repeat

This one represents a different situation where, again, the [1/0] process starts executing but the debug request gets stuck (deferred) in the UI process because the UI process is "busy" executing its Workspace task.

We concluded that this looks like a more complex scenario than the "blocked UI" scenario presented above.

The more I think about it the more I lean toward treating both scenarios equally, i.e. create a new UI in both scenarios, in other words create a new UI for every debug request.

The main difference between the two scenarios is *where* - at which queue the UI process is waiting when the debug request occurs: whether on a Semaphore or on a Processor's ready list (apologies for stating the obvious: the UI process is waiting somewhere by definition when a debug request from another process occurs). I'm aware my experience is very limited but I can't come up with any argument why *not* treat them equally :) Treating them equally looks to me cleaner, simpler and may even allow some more simplifications.

Here's my suggestion (as usual I'm not sure I'm placing my modification at the most appropriate location but you get the idea):

newUIProcessIfNeeded
                "If the system needs a UIProcess (we know because UIProcess is not nil),
                then ensure that the UIProcess is ready to run, in order to have a responsive UI.
                If we needed to create a new UI process, answer the old one, as it is most likely the
                process the user is interested in debugging. See senders."

                UIProcess ifNotNil: [ :oldUIProcess |
                                self spawnNewMorphicProcessFor: UI.
                                ^oldUIProcess ].
                ^nil

With this change the following examples work:

[1/0] fork.
Processor yield.
[ 10000 factorial ] repeat

[1/0] fork.
[ 10000 factorial. Processor yield ] repeat


Surprisingly, even the following example works, i.e. opens a debugger instead of getting stuck, but in this case it is also thanks to some unrelated interrupts at play preempting the old UI and allowing the new UI run..

[1/0] fork.
[ 10 factorial ] repeat


An interesting observation:

The suggested modification works under the assumption that
                Smalltalk processPreemptionYields
returns true, which is Cuis's default (unlike Squeak's); once you change it to false, i.e. once you change the order ready processes are placed in the Processor's ready queue, it won't work; 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.


To conclude: if you won't find some fatal flaw with this approach it seems to me it allows to run code fragments in the UI as usual but once a more complex scenario occurs, like a parallel process requesting a debugger, a new UI is created to take over so that the old UI process can continue executing its unfinished task without the need to act as a UI any longer (and will automatically terminate once it finishes its current cycle).

Again, I'll very much appreciate any comments or suggestions you might have; thanks for your time and patience reading such long message :)

Best,
Jaromir


--

Jaromír Matas

mail at jaromir.net

From: Juan Vuletich<mailto:JuanVuletich at zoho.com>
Sent: Friday, July 15, 2022 1:26
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Cc: Juan Vuletich<mailto:JuanVuletich at zoho.com>; Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] FW: FW: FW: Freezing UI - can't interrupt via Alt+.

Hi Jaromir,

On 7/14/2022 4:49 PM, Jaromir Matas via Cuis-dev wrote:

Hi Juan,

Gosh, this is amazing! I couldn't wait to see :)

I ran out of mean examples :D

Fun, Fun, Fun!

One observation though: Sometimes, although rarely and irregularly, this happens:

I run an example (in the Workspace), e.g. this one:

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

and then I move the first debugger window and close it before the 5 second delay expires and when the second debugger opens I get an MNU error concerning drawing - I'm enclosing a snip (if I knew how to file out the debugger's stack contents I'd send it too). And the next time you run the same example it may happen again or may not... Can't figure out any pattern except you have to move the first debugger window before closing it.

Oh, yes. Letting the old Morphic process end by itself may mean that there is more than one process trying to draw the world. And if some higher priority process wakes up, maybe the other morphic process is scheduled next. Just pushed a couple of tweaks to reduce the risk as much as possible.

--
One stupid question: How do you make the image download the latest changes you made at github? I thought this would work: World menu -> changes -> install new updates but it doesn't... Now I think it's maybe not supposed to download from github but just locally from the CoreUpdates folder... Is that so?

Yes. The base image doesn't even include networking code. It will only access local files.

What I do now (sorry if it sounds too stupid) is I download a new image which contains the latest changes in the CoreUpdates folder already...

The thing is I'm on Windows and don't do any git stuff or any command line stuff ;) Is there a way for users like me to update easily?

The alternative would be to grab the update files from github using the web browser. Could be even more tedious that grabbing a full zip file each time. The alternative is to use git, of course. I use git in Windows each time I save new Cuis images, as it is easier to run 32 bit systems than in Linux or MacOS. Just open the git bash and do git pull. Actually, I wouldn't be surprised if the Linux subsystem for Windows already includes git.

--
Well, actually, what would think about situations like this:

[1/0] fork.
[ 10000 factorial. Processor yield ] repeat

would you expect, or consider reasonable to expect, the UI to process the 1/0 exception during the long computation?

I'd tend to say no but then when I look at this example:

[1/0] fork.
[ 10000 factorial. 5 seconds asDelay wait ] repeat

I'm not so sure... The delay blocks the UI and a thus a new UI is created etc. while in the former case yield just allows other processes of the same priority to run etc… which are implementation details…

And if you run the former example forked:

[[1/0] fork.
[ 10000 factorial. Processor yield ] repeat] fork

You won’t be surprised the 1/0 exception is executed immediately after the first yield. Which leads me closer to expecting the 1/0 exception appear after the first yield even in the former example. I believe the computation’s result shouldn’t depend on whether it runs in the UI or not.

I'm curious to know your opinion.

Many thanks,
jaromir

Interesting examples. I think there are arguments to support both sides. So, far, I'm OK with firing a new UI process if the current one is blocked, suspended or terminated. Likely the user is trying to recover control using cmd+. But starting a new UI process only because the current one is busy, is something that would require making all morphic fully multithreading. I don't think the complexity is worth, at least unless we see a "real world" need.

If the programmer started a long computation in the UI process by mistake, they can cmd + . to recover control, and then try something better (perhaps fork the workload). If they did it on purpose, well, then they actually asked for the UI to be unresponsive during that time.

If we changed this, not only the Morphic framework should be multithreading safe. Also all application code: Application level code could be busy updating data, while on a separate process the user tries to use it or modify it in some other way. We'd be forcing all app developers to be "parallel processing aware", even if they are writing simple code. I prefer to let those, willing to do heavy processing -and- have a responsive UI at the same time,  find a suitable design.

Hope this makes sense to you.

Cheers!


--

Juan Vuletich

www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev

https://github.com/jvuletich

https://www.linkedin.com/in/juan-vuletich-75611b3

https://independent.academia.edu/JuanVuletich

https://www.researchgate.net/profile/Juan-Vuletich

https://patents.justia.com/inventor/juan-manuel-vuletich

https://twitter.com/JuanVuletich


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

More information about the Cuis-dev mailing list