<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, I’m attaching a changeset that would evaluate the following examples identically, i.e. regardless of whether the code runs in the UI or a non-UI process (simulated by wrapping into fork); please let me know what you think if you find some time. <o:p> </o:p> s := Semaphore new. [[1/0] ensure: [s signal]] fork. s wait. self error: 'error' <o:p> </o:p> [s := Semaphore new. [[1/0] ensure: [s signal]] fork. s wait. self error: 'error'] fork <o:p> </o:p> I’m still just trying to analyze what is a reasonable requirement as for the semantics and the suggested code I just a rough idea for your review; I don’t have enough experience to see the bigger picture. <o:p> </o:p> Thanks a lot, jaromir <o:p> </o:p> -- Jaromír Matas<o:p></o:p> 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:cuis-dev@lists.cuis.st">Jaromir Matas via Cuis-dev</a> Sent: Monday, July 4, 2022 17:56 To: <a href="mailto:JuanVuletich@zoho.com">Juan Vuletich</a>; <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> Hi Juan<o:p></o:p> <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> <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> <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> <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> <o:p> </o:p> #mainLoop<o:p></o:p> <o:p></o:p> self clearWaitDelay.<o:p></o:p> canvas isNil ifTrue: [<o:p></o:p> self setMainCanvas ].<o:p></o:p> self redrawNeeded.<o:p></o:p> [<o:p></o:p> self doOneCycle.<o:p></o:p> UISupervisor uiProcess isActiveProcess ] "<----- a test in the spirit of whether the active process really is the current UI process"<o:p></o:p> whileTrue: []<o:p></o:p> <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> <o:p> </o:p> Does this sound like a reasonable approach or just another potential can of worms? :)<o:p></o:p> <o:p> </o:p> Many thanks,<o:p></o:p> Jaromir<o:p></o:p> <o:p> </o:p> -- Jaromír Matas<o:p></o:p> +420 777 492 777 mail@jaromir.net <o:p> </o:p> <div style="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+.<o:p></o:p> </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> <o:p> </o:p> </div> </body> </html>