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

[Juan Vuletich]

On 7/4/2022 12:56 PM, Jaromir Matas via Cuis-dev wrote:
>
> 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
>
>

Hi Jaromir,

Doing that properly would require detecting possible inconsistencies in 
the Morphic object structure, as now we'd be modifying Morphic state 
from two different processes. Giving reasonable guarantees of not 
completely breaking the various invariants would require a lot of 
complexity. Doing it without any such guarantees is not worth it in my 
opinion.

I think (hope!) that anyone facing these kind of situations is an 
experienced Morphic developer, who should better understand what's going 
on, and code what they are doing with processes carefully enough. People 
not messing with the Morphic UI process should never face this kind of 
trouble. In many years of doing Morphic, I only faced trouble when doing 
deep redesign of the core classes, and what I did is to be sure that it 
is easy enough to start a new Morphic World in a new Morphic Process if 
needed.

Thanks,

-- 
Juan Vuletich
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/cdf8f809/attachment.htm>