<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="#954F72" style="word-wrap:break-word"> <div class="WordSection1"> Hi Juan <o:p> </o:p> > 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. <o:p> </o:p> > 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. <o:p> </o:p> 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). <o:p> </o:p> 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 <o:p> </o:p> #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: [] <o:p> </o:p> 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. <o:p> </o:p> Does this sound like a reasonable approach or just another potential can of worms? :) <o:p> </o:p> Many thanks, Jaromir <o:p> </o:p> -- Jaromír Matas<o:p></o:p> +420 777 492 777 mail@jaromir.net <o:p> </o:p> <div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: <a href="mailto:JuanVuletich@zoho.com">Juan Vuletich</a> Sent: Monday, July 4, 2022 17:11 To: <a href="mailto:cuis-dev@lists.cuis.st">Discussion of Cuis Smalltalk</a> Cc: <a href="mailto:mail@jaromir.net">Jaromir Matas</a> Subject: Re: [Cuis-dev] FW: Freezing UI - can't interrupt via Alt+. </div> <o:p> </o:p> On 7/3/2022 5:48 AM, Jaromir Matas via Cuis-dev wrote: <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> Hi Juan,<o:p></o:p> <o:p></o:p> I hate to bring bad news but I’m afraid there’s still one outstanding issue ;)<o:p></o:p> <o:p></o:p> s := Semaphore new.<o:p></o:p> [1/0. s signal] fork.<o:p></o:p> s wait.<o:p></o:p> Transcript cr; show: 'done'<o:p></o:p> <o:p></o:p> 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.<o:p></o:p> <o:p></o:p> 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:<o:p></o:p> <o:p></o:p> [s := Semaphore new.<o:p></o:p> [1/0. s signal] fork.<o:p></o:p> s wait.<o:p></o:p> Transcript cr; show: 'done'] fork<o:p></o:p> <o:p></o:p> I look forward to hearing from you again, many thanks!<o:p></o:p> <o:p></o:p> PS: I tried resuming instead of terminating the oldUIProcess but that of course ends up infamously with two UI processes ;)<o:p></o:p> <o:p></o:p> Best,<o:p></o:p> Jaromir<o:p></o:p> --<o:p></o:p> Jaromír Matas<o:p></o:p> <a href="mailto:mail@jaromir.net">mail@jaromir.net</a><o:p></o:p> <o:p></o:p> <o:p> </o:p> </blockquote> 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, <o:p></o:p> <pre>-- </pre> <pre>Juan Vuletich</pre> <pre><a href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a></pre> <pre><a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a></pre> <pre><a href="https://github.com/jvuletich">https://github.com/jvuletich</a></pre> <pre><a href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a></pre> <pre><a href="https://independent.academia.edu/JuanVuletich">https://independent.academia.edu/JuanVuletich</a></pre> <pre><a href="https://www.researchgate.net/profile/Juan-Vuletich">https://www.researchgate.net/profile/Juan-Vuletich</a></pre> <pre><a href="https://patents.justia.com/inventor/juan-manuel-vuletich">https://patents.justia.com/inventor/juan-manuel-vuletich</a></pre> <pre><a href="https://twitter.com/JuanVuletich">https://twitter.com/JuanVuletich</a></pre> <o:p> </o:p> </div> </body> </html>