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

[Jaromir Matas]

Hi Juan

> We could try resuming the old process. That would require detecting that a new UI process was created and terminate it. I don't like this, because it may be the new process the one that is doing relevant stuff now. Besides, this could lead to state corruption, depending (for example) on the state of method temp variables in both processes.

> I think it is reasonable to state that the UI process, as the other system created processes are a bit special: The system needs to guarantee that there is always an UI process ready to run. This might mean the system messing with these processes occasionally. People wanting to have absolute control over processes should fork their own.

I've been thinking about it and yes, controlling two UIs is unreasonably complicated; a reasonable solution has to be simple and straightforward otherwise it's better leave as it is (I mean keep your great update #5347 keeping the UI always available for new exceptions).

I've just tested one more approach in Squeak; the idea is: To keep the system responsive if the UI is blocked, start a new UI process in #newProcessIfUI: and let the old (blocked) one wait and eventually finish its *last cycle* and then automatically*terminate*; to make sure the old UI terminates automatically you could e.g. add a simple test to the #mainLoop

#mainLoop

                self clearWaitDelay.
                canvas isNil ifTrue: [
                                self setMainCanvas ].
                self redrawNeeded.
                [
                                self doOneCycle.
                                UISupervisor uiProcess isActiveProcess ]    "<----- a test in the spirit of whether the active process really is the current UI process"
                                                whileTrue: []

In Squeak this approach seems to work but Cuis has a different (a bit more complicated) implementation and I haven't managed to implement the idea correctly.

Does this sound like a reasonable approach or just another potential can of worms? :)

Many thanks,
Jaromir


--

Jaromír Matas

+420 777 492 777
mail at jaromir.net

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

On 7/3/2022 5:48 AM, Jaromir Matas via Cuis-dev wrote:
Hi Juan,

I hate to bring bad news but I’m afraid there’s still one outstanding issue ;)

s := Semaphore new.
[1/0. s signal] fork.
s wait.
Transcript cr; show: 'done'

If you terminate a blocked UI it means it won’t be able to continue when signaled and won’t print ‘done’ in this case.

This feels like a natural requirement for the blocked UI to continue because if it was just a regular non-UI process we would want it continue too, I guess; like this:

[s := Semaphore new.
[1/0. s signal] fork.
s wait.
Transcript cr; show: 'done'] fork

I look forward to hearing from you again, many thanks!

PS: I tried resuming instead of terminating the oldUIProcess but that of course ends up infamously with two UI processes ;)

Best,
Jaromir

--

Jaromír Matas

mail at jaromir.net<mailto:mail at jaromir.net>



We could try resuming the old process. That would require detecting that a new UI process was created and terminate it. I don't like this, because it may be the new process the one that is doing relevant stuff now. Besides, this could lead to state corruption, depending (for example) on the state of method temp variables in both processes.

I think it is reasonable to state that the UI process, as the other system created processes are a bit special: The system needs to guarantee that there is always an UI process ready to run. This might mean the system messing with these processes occasionally. People wanting to have absolute control over processes should fork their own.

Thanks,


--

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/20220704/9d0c1d06/attachment-0001.htm>