<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=iso-8859-1"> <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> Thank you very much for your brilliant explanations! Many missing pieces start to fit for me, thanks :) <o:p> </o:p> Enclosing the .cs <o:p> </o:p> > The implementation in Object is just to avoid creating references to UISupervisor all over the place <o:p> </o:p> Makes perfect sense; I've just realized what confused me: the use of 'true' as a receiver :) I expected something like <o:p> </o:p> `self runningWorld` <o:p> </o:p> Sorry for the confusion, all clear now ;) <o:p> </o:p> > #processPreemptionYields = false is the intended behavior in Smalltalk-80 <o:p> </o:p> Ahhh, I didn't know! <o:p> </o:p> > In Cuis, no assumption is made. The way to protect access to Morphic state is to call #whenUIinSafeState: . So, #processPreemptionYields can be set to true. I believe this is what most people would expect in these days. <o:p> </o:p> Yes! That was my naďve expectation when I started with Smalltalk (not long ago) but was utterly confused by Squeak's reverting (and sticking) to the cooperative mode. Preemptive multitasking is indeed less restricted and offers no "cheap" guarantee the processes of the same priority won't interleave (yield) but that's part of the fun to make things work even without the assumption :D <o:p> </o:p> Many thanks again for the brain food :) Best, Jaromir -- 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:juan@cuis.st">Juan Vuletich</a> Sent: Wednesday, August 10, 2022 15:41 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: FW: FW: Freezing UI - can't interrupt via Alt+. </div> <o:p> </o:p> Hi Jaromir, On 8/10/2022 9:24 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 very much like your simplifying the code opening a debugger :)<o:p></o:p> <o:p></o:p> I'm still just skimming the surface of the UI implementation but I'd like to ask a few questions:<o:p></o:p> <o:p></o:p> (1) why is there Object >> #runningWorld <o:p></o:p> - wouldn't sending `UISupervisor runningWorld` instead of `true runningWorld` be sufficient e.g. in Debugger >> #openWindowLabel:usePreDebugWindow:preDebugMessage:?<o:p></o:p> </blockquote> Yes, of course. The implementation in Object is just to avoid creating references to UISupervisor all over the place, in case some day we want to replace it with something else. It is just that I wasn't so sure about UISupervisor when I created it. Not a big deal, IMO. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> (2) Why not define UISupervisor >> runningWorld via #animatedUIOf: to avoid code duplicity?<o:p></o:p> <o:p></o:p> UISupervisor >> runningWorld<o:p></o:p> "<o:p></o:p> UISupervisor runningWorld<o:p></o:p> [ UISupervisor runningWorld print ] fork<o:p></o:p> "<o:p></o:p> ^self animatedUIOf: Processor activeProcess<o:p></o:p> </blockquote> Yeah. Good idea. Just post the .cs, so it has your initials :) <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> (3) I understand your intention when you lowered the former UI process's priority in #spawnNewMorphicProcessFor: by one; I believe it was in response to this example:<o:p></o:p> <o:p></o:p> [1/0] fork.<o:p></o:p> 5 seconds asDelay wait.<o:p></o:p> self error: 'error'<o:p></o:p> <o:p></o:p> I've been wondering whether it's still relevant after your most recent changes - and unfortunately it seems that it is: changing the former UI process's priority back to the active priority will cause redraw glitches (e.g. Transcript background color in Dark mode won't display properly). <o:p></o:p> <o:p></o:p> However, there seems to be a very similar redraw blip *despite* the lower priority tweak when running e.g.<o:p></o:p> [1/0] fork.<o:p></o:p> [1/0] fork<o:p></o:p> ... the Transcript window won't get redrawn correctly in the Dark mode: it won't change its background color properly. It puzzles me why the Transcript window is the only one affected.<o:p></o:p> </blockquote> The Transcript is special. It will do the same in any Theme, although the difference may be less obvious. Try `1 to: 4 do: [ :i | i print. 100000 factorial ]` in a Workspace. Do it with another window partially covering the Transcript. The thing here is that the Transcript gets immediate updates, without waiting for the next Morphic cycle. This is extremely useful for debugging, and especially for debugging Morphic itself. Browse a bit Transcript and you'll see. The reason to lower the older Morphic priority is to guarantee a responsive UI, a focus of yours in the last months. Besides, given that (see below) in Cuis two processes of the same priority can interrupt each other at any time, and given that Morphic is not thread safe, then, as we want the old Morphic process to finish its stuff (as many of your examples required), we need to make that with a lower priority than the main UI process, to reduce the risk of the old process breaking state needed by the new one. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> What I'm trying to figure out is: if the computation carried out by this former UI process involves references to Processor activePriority the priority-lowering tweak may change the semantics of a computation involving forking processes at different relative priorities (in other words changing the priority of the process in the middle of the computation by an *unrelated* "outsider" process feels dangerous); just a theoretical idea though, unfortunately I don't have any practical example or any further suggestion; I'll return to this later after some more educating myself :)<o:p></o:p> </blockquote> But it is not an *unrelated* process. It is the UISupervisor, who created it in the first place, gave it the chore of running the World, and is now replacing it with a new one. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> About the processPreemptionYields flag:<o:p></o:p> <o:p></o:p> > I think it would be important to understand why would someone want #processPreemptionYields = false. Their reasons for requesting a process to never yield to others of same priority (even if some higher process wakes up in between) may also mean they don't want new UI processes to be started so lightly.<o:p></o:p> <o:p></o:p> Here's Eliot's explanation why he chose #processPreemptionYields = false over the previous functionality: <a href="https://forum.world.st/about-signal-tp5109735p5109862.html">https://forum.world.st/about-signal-tp5109735p5109862.html</a><o:p></o:p> </blockquote> I know. I've been here since before Squeak ran Morphic, and it was MVC only. I understand MVC process scheduling in Smalltalk-80 and its evolution through Morphic. #processPreemptionYields = false is the intended behavior in Smalltalk-80. In Smalltalk-80 a process can only be preempted by one of a higher priority. This means that no real access protection is needed between processes of the same priority (given that they only #yield at safe places). This is akin to Corroutines (and #resumeNext semantics). But the original Squeak VM, when resuming a high priority process, will put the active process at the back of the process queue, possibly breaking older code. This is the #processPreemptionYields = true behavior. Squeak needed then to adapt to this behavior. Much later, Eliot added the #processPeemptionYields = false to restore the original Smalltalk-80 intended behavior, which could be safer for code unaware of these issues. In Cuis, no assumption is made. The way to protect access to Morphic state is to call #whenUIinSafeState: . So, #processPreemptionYields can be set to true. I believe this is what most people would expect in these days. The last mainstream OS that switched from "cooperative multitasking" to "preemptive multitasking" was MacOS about 20 years ago! <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> My understanding is he simply thinks #processPreemptionYields = true produces an inconsistent/erroneous behavior in the sense that unless a process *explicitly* yields control it should stay in control (unless preempted by a higher priority process in which case it should get back control once the higher priority process gives up control, i.e. stay at the front of the run queue). <o:p></o:p> <o:p></o:p> In case of Squeak (which is on #processPreemptionYields = false) each world cycle does contain an explicit yield anyway so opening each debugger in a new UI doesn't seem to clash with this stricter cooperative-within-priorities scheduling approach imho :)<o:p></o:p> <o:p></o:p> A while ago I asked Marcel about the preemption modes and the answer was (roughly) that #processPreemptionYields = false offers more predictability (understandably) plus something about thread-safe-ness of Morphic structures (which is still way beyond my skills level).<o:p></o:p> <o:p></o:p> Is there a reason why you'd prefer #processPreemptionYields = true or is it just for historic reasons? ("why fix something that works" type of situation? :) )<o:p></o:p> </blockquote> Absolutely the contrary! #processPreemptionYields = false is to keep the Smalltalk-80 cooperative multitasking style that was widespread until mid 90's, when Linux and Windows made the transition, followed a few years later by MacOS. In Cuis we explicitly made the change to #processPreemptionYields = true about a decade ago to be in line with modern practice. In doing so, I needed to come up with #whenUIinSafeState: and make sure that nothing broke. Another situation where Cuis favors progress in spite of back compatibility. <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <o:p></o:p> <o:p></o:p> Thanks again very much for discussing these issues!<o:p></o:p> <o:p></o:p> Best regards,<o:p></o:p> Jaromir<o:p></o:p> <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> </blockquote> Cheers, <o:p></o:p> <pre>-- </pre> <pre>Juan Vuletich</pre> <pre>cuis.st</pre> <pre>github.com/jvuletich</pre> <pre>researchgate.net/profile/Juan-Vuletich</pre> <pre>independent.academia.edu/JuanVuletich</pre> <pre>patents.justia.com/inventor/juan-manuel-vuletich</pre> <pre>linkedin.com/in/juan-vuletich-75611b3</pre> <pre>twitter.com/JuanVuletich</pre> <o:p> </o:p> </div> </body> </html>