<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi Jaromir, On 8/1/2022 9:38 AM, Jaromir Matas via Cuis-dev wrote: <blockquote cite="mid:BL0PR03MB406578B373B738CD7FAF7EF9EE9A9@BL0PR03MB4065.namprd03.prod.outlook.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> <div class="WordSection1"> Hi Juan, <o:p> </o:p> In our previous discussion we discussed a few examples: <o:p> </o:p> [1/0] fork. [ 10000 factorial. 5 seconds asDelay wait ] repeat <o:p> </o:p> This one represents a situation where the UI is blocked and we (mostly you indeed) modified the code to create a new UI to open the debugger for the [1/0] process request while the old UI is idly waiting. </div> </blockquote> Right. <blockquote cite="mid:BL0PR03MB406578B373B738CD7FAF7EF9EE9A9@BL0PR03MB4065.namprd03.prod.outlook.com" type="cite"> <div class="WordSection1"> <o:p> </o:p> [1/0] fork. [ 10000 factorial. Processor yield ] repeat <o:p> </o:p> This one represents a different situation where, again, the [1/0] process starts executing but the debug request gets stuck (deferred) in the UI process because the UI process is "busy" executing its Workspace task. <o:p> </o:p> We concluded that this looks like a more complex scenario than the "blocked UI" scenario presented above. </div> </blockquote> My thought was that 'you asked your UI process to be busy, so you don't get UI'. <blockquote cite="mid:BL0PR03MB406578B373B738CD7FAF7EF9EE9A9@BL0PR03MB4065.namprd03.prod.outlook.com" type="cite"> <div class="WordSection1"> The more I think about it the more I lean toward treating both scenarios equally, i.e. create a new UI in both scenarios, in other words create a new UI for every debug request. </div> </blockquote> Ok. Yes, this was enough to convince me. The debugger is a special tool. It is reasonable to always start a fresh UI process for it. In OS level debuggers, common practice is to start a debugger (in its own OS process) and then 'attach' it to the process being debugged. Makes sense. <blockquote cite="mid:BL0PR03MB406578B373B738CD7FAF7EF9EE9A9@BL0PR03MB4065.namprd03.prod.outlook.com" type="cite"> <div class="WordSection1"> The main difference between the two scenarios is *where* - at which queue the UI process is waiting when the debug request occurs: whether on a Semaphore or on a Processor's ready list (apologies for stating the obvious: the UI process is waiting somewhere by definition when a debug request from another process occurs). I'm aware my experience is very limited but I can't come up with any argument why *not* treat them equally :) Treating them equally looks to me cleaner, simpler and may even allow some more simplifications. <o:p> </o:p> Here's my suggestion (as usual I'm not sure I'm placing my modification at the most appropriate location but you get the idea): <o:p> </o:p> newUIProcessIfNeeded "If the system needs a UIProcess (we know because UIProcess is not nil), then ensure that the UIProcess is ready to run, in order to have a responsive UI. If we needed to create a new UI process, answer the old one, as it is most likely the process the user is interested in debugging. See senders." <o:p> </o:p> UIProcess ifNotNil: [ :oldUIProcess | self spawnNewMorphicProcessFor: UI. ^oldUIProcess ]. ^nil </div> </blockquote> It is reasonable to try that as an experiment, but if you follow the several chains of senders to #spawnNewMorphicProcessFor: , you'll see this got to dirty, because of making many small, unrelated changes over the years. In the current shape of the code it is hard to guarantee that all requests to open a debugger behave in a consistent way. So, I spent a couple of days refactoring and cleaning it. The result is 18 cleanup & refactor changesets, that shouldn change behavior much, and one single change that essentially does what you suggest, but it is now much easier to follow. I pushed this to github yesterday. The change sets that starts a new process for every debugger (except when the user debugs an expression) is in change set #5434. <blockquote cite="mid:BL0PR03MB406578B373B738CD7FAF7EF9EE9A9@BL0PR03MB4065.namprd03.prod.outlook.com" type="cite"> <div class="WordSection1"> With this change the following examples work: <o:p> </o:p> [1/0] fork. Processor yield. [ 10000 factorial ] repeat <o:p> </o:p> [1/0] fork. [ 10000 factorial. Processor yield ] repeat <o:p> </o:p> <o:p> </o:p> Surprisingly, even the following example works, i.e. opens a debugger instead of getting stuck, but in this case it is also thanks to some unrelated interrupts at play preempting the old UI and allowing the new UI run.. <o:p> </o:p> [1/0] fork. [ 10 factorial ] repeat </div> </blockquote> <o:p></o:p> Yep. All these work as expected now. It is interesting to open a ProcessBrowser, though, and see how the 'former UI process' is still busy computing factorials! <o:p> </o:p> <blockquote cite="mid:BL0PR03MB406578B373B738CD7FAF7EF9EE9A9@BL0PR03MB4065.namprd03.prod.outlook.com" type="cite"> <div class="WordSection1"> An interesting observation: <o:p> </o:p> The suggested modification works under the assumption that Smalltalk processPreemptionYields returns true, which is Cuis's default (unlike Squeak's); once you change it to false, i.e. once you change the order ready processes are placed in the Processor's ready queue, it won't work; the preemption mode is critical in this case so I'll have to figure out how to make this work for Squeak :D Or better yet how to make it independent of the processPreemptionYields setting. </div> </blockquote> <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> <blockquote cite="mid:BL0PR03MB406578B373B738CD7FAF7EF9EE9A9@BL0PR03MB4065.namprd03.prod.outlook.com" type="cite"> <div class="WordSection1"> To conclude: if you won't find some fatal flaw with this approach it seems to me it allows to run code fragments in the UI as usual but once a more complex scenario occurs, like a parallel process requesting a debugger, a new UI is created to take over so that the old UI process can continue executing its unfinished task without the need to act as a UI any longer (and will automatically terminate once it finishes its current cycle). <o:p> </o:p> Again, I'll very much appreciate any comments or suggestions you might have; thanks for your time and patience reading such long message :) <o:p> </o:p> Best, Jaromir <o:p> </o:p> -- Jaromír Matas<o:p></o:p> <a class="moz-txt-link-abbreviated" href="mailto:mail@jaromir.net">mail@jaromir.net</a> </div> </blockquote> Thanks a lot for trying all these things, suggesting course of action, and especially thank you for the great discussion. It is always great to be able to talk about these issues. And Cuis is always improving this way! Cheers, <pre class="moz-signature" cols="72">-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich</pre> </body> </html>