<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Jaromir, On 8/2/2022 7:05 PM, Jaromir Matas via Cuis-dev wrote: <blockquote cite="mid:DM6PR03MB40737C8EAE89D99303E6FCA2EE9D9@DM6PR03MB4073.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> I'd like to share my analysis regarding the dependence of the solution presented in my previous message on the choice of the preemption mode (i.e. whether preempting a process involves an implicit yield like in Cuis/Pharo or without the yield like in Squeak, indicated by #processPreemptionYields value true or false, which is in fact Eliot's improvement over the Blue book applied in Squeak currently). <o:p> </o:p> I wrote: <o:p> </o:p> > [...] 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. <o:p> </o:p> Now I think the behavior *is* supposed to be different for different preemption modes, so there's nothing different to do for Squeak. Compare the following examples: <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> In the first example the UI places the [1/0] process in the run queue and continues to execute the #yield which allows the [1/0] process run, encounter the error, open a new UI, place it in the run queue behind the former UI and suspend itself. Then the former UI resumes again and keeps computing factorials in the repeat cycle. <o:p> </o:p> Now comes the crucial point: in Squeak with processPreemptionYields = false the former UI keeps computing factorials and never lets the new UI take over (even when interrupted) and hence no debugger opens, while in Cuis where processPreemptionYields = true the former UI computing the factorials is interrupted from time to time by a higher priority process (time watcher?) which causes the former UI do implicit yield and move to the end of the run queue which allows the new UI do one cycle, open a debugger and just keep the UI responsive. </div> </blockquote> Exactly. <blockquote cite="mid:DM6PR03MB40737C8EAE89D99303E6FCA2EE9D9@DM6PR03MB4073.namprd03.prod.outlook.com" type="cite"> <div class="WordSection1"> In my opinion both behaviors are correct and should be expected based on the choice of the preemption mode. <o:p> </o:p> In the second example the #yield inside the repeat loop does explicitly more or less what the implicit yield does when processPreemptionYields = true so the resulting behavior is the same regardless of the preemption mode. </div> </blockquote> Right. In my (just sent) answer to the previous email I also said that if the user set #processPreemptionYields = false, they should have their reasons. <blockquote cite="mid:DM6PR03MB40737C8EAE89D99303E6FCA2EE9D9@DM6PR03MB4073.namprd03.prod.outlook.com" type="cite"> <div class="WordSection1"> One more point: when you wrap both examples in fork, i.e. when you run the examples in a non-UI process the behavior is identical as when they run in the UI; I guess this is important. <o:p> </o:p> [ [1/0] fork. Processor yield. [ 10000 factorial] repeat] fork <o:p> </o:p> [ [1/0] fork. [ 10000 factorial. Processor yield] repeat] fork <o:p> </o:p> Thanks for your time; I'm sure nothing of it is news for you but at least for me looking at it from the UI angle has been an interesting and sometimes surprising exercise :) <o:p> </o:p> Thanks again, 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> The truth is that "in theory" there was nothing new, i.e. I already knew the specification for the behaviors. But "in practice", many of these examples were surprising to me, and they took quite a bit of thought to understand them, and to see that they were actually following the specification. And then, the important part: To decide if the observed (and now understood) behavior is what we want, or if what we expected before running the example is what should happen. This triggers the hard work, the new insights, and the better code. Thank you! <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>