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

Jaromir Matas mail at jaromir.net
Mon Aug 1 05:38:05 PDT 2022 

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/20220801/224e5844/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UISupervisor class-newUIProcessIfNeeded.st
Type: application/octet-stream
Size: 581 bytes
Desc: UISupervisor class-newUIProcessIfNeeded.st
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220801/224e5844/attachment-0001.obj>

More information about the Cuis-dev mailing list