<!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 4/14/2021 5:37 AM, Jaromir Matas via Cuis-dev wrote: <blockquote cite="mid:BN7PR08MB3842F3849FF9C29E23161C46EE4E9@BN7PR08MB3842.namprd08.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, hi all, <o:p> </o:p> I’m enclosing an amended list of examples with fixed #fork and ‘self error’ patterns so that you can use them right away. </div> </blockquote> Thanks! <blockquote cite="mid:BN7PR08MB3842F3849FF9C29E23161C46EE4E9@BN7PR08MB3842.namprd08.prod.outlook.com" type="cite"> <div class="WordSection1"> <o:p> </o:p> > - The notes for a few examples speak of crashes in Cuis. I pushed some fixes a few days ago, <o:p></o:p> > and now cmd-. works as expected. The examples behave the same as in Squeak. <o:p></o:p> <o:p> </o:p> Yes, it’s perfect :) I removed the crash notes from the example list. </div> </blockquote> Thanks. <blockquote cite="mid:BN7PR08MB3842F3849FF9C29E23161C46EE4E9@BN7PR08MB3842.namprd08.prod.outlook.com" type="cite"> <div class="WordSection1"> A little correction: I haven’t realized Martin McClure was talking from a Visual Works position - they have different semantics of #valueUninterruptably (at least in 8.3 from 2017, using a semaphore). <o:p> </o:p> The Squeak semantics of #valueUninterruptably is “don’t let anything kill me” (using a non-local return in the unwind block). </div> </blockquote> Yes. In Cuis we don't have that method. I don't quite see the use case for it. In any case, I think I prefer Martin and Esteban Maringolo's: valueEnsured "Protect against process termination. Suggested by Esteban Maringolo at Martin McClure's 'Threads, Critical Sections, and Termination' (Smalltalks 2019 conference)" [] ensure: self <blockquote cite="mid:BN7PR08MB3842F3849FF9C29E23161C46EE4E9@BN7PR08MB3842.namprd08.prod.outlook.com" type="cite"> <div class="WordSection1"> Best regards, Jaromir </div> </blockquote> Finally, I took a look at your first example requiring user operation of the debugger. The debugger tells the suspended process #terminate (on debugger close) or #resume (on debugger proceed). So this example of yours: [ [ ] ensure: [ [self error: 'unwind test'] ensure: [ Transcript show: 'x1']. Transcript show: 'x2'] ] ensure: [ Transcript show: 'x3']. Transcript show: 'x4' ended up looking: p := [ [ [ ] ensure: [ [p suspend] ensure: [ Transcript show: 'x1']. Transcript show: 'x2'] ] ensure: [ Transcript show: 'x3']. Transcript show: 'x4' ] newProcess. p resume. Processor yield. "p terminate." "Equivalent to closing the debugger" "p resume." "Equivalent to [proceed] in the debugger" which is essentially the same as the first example in your txt. So, if you are willing to turn all these examples into tests, I think that using the first version, that doesn't activate the debugger is ok. Maybe adding the #resume case (to assert that all the prints are run), and maybe adding the non-local return variant is worth doing, though. WRT the `suspendedContext pc > suspendedContext startpc` condition in #terminate, you were completely right, and I got confused. Apologies. Still, it seems that that code was originally written knowing the specific details in #newProcess. In any case your version of #terminate is a cleaner alternative. Thanks again for your hard work! Cheers, <blockquote cite="mid:BN7PR08MB3842F3849FF9C29E23161C46EE4E9@BN7PR08MB3842.namprd08.prod.outlook.com" type="cite"> <div class="WordSection1"> <o:p> </o:p> <div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;"> From: <a moz-do-not-send="true" href="mailto:cuis-dev@lists.cuis.st">Jaromir Matas via Cuis-dev</a> Sent: Wednesday, April 14, 2021 0:20 To: <a moz-do-not-send="true" href="mailto:juan@jvuletich.org">Juan Vuletich</a>; <a moz-do-not-send="true" href="mailto:cuis-dev@lists.cuis.st"> Discussion of Cuis Smalltalk</a> Cc: <a moz-do-not-send="true" href="mailto:mail@jaromir.net">Jaromir Matas</a>; <a moz-do-not-send="true" href="mailto:hernan.wilkinson@10pines.com"> Hernan Wilkinson</a> Subject: Re: [Cuis-dev] Unwind mechanism during termination is broken and inconsistent </div> <o:p> </o:p> Hi Juan,<o:p></o:p> <o:p> </o:p> ><o:p> </o:p> > Hi Jaromir, hi all,<o:p></o:p> ><o:p> </o:p> > This is a most impressive work!<o:p></o:p> <o:p> </o:p> Many thanks for your encouragement - I'm really glad you like it :)<o:p></o:p> <o:p> </o:p> ><o:p> </o:p> > It made me remember this talk given by Martin McClure in Smalltalks 2019: <a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=AvM5YrjK9AE">https://www.youtube.com/watch?v=AvM5YrjK9AE</a> . At minute 22:00, Martin states the behavior he expects from #terminate, and shows a test. I tried his test in Cuis, and sometimes (but not always) it failed. Jaromir, with your code, Martin's test now pass! In addition, I ran the existing Process tests, and none is made to fail.<o:p></o:p> <o:p> </o:p> Very interesting: I haven't touched the part for releasing critical sections (I thought it was an independent part I wanted to revisit later) but I'm relieved to hear it works properly with the proposed changes :) <o:p></o:p> <o:p> </o:p> In the talk Martin McClure also mentioned #valueUninterruptably. I've noticed Cuis doesn't implement it but I think with the suggested #terminate it could be implemented safely (fingers crossed). <o:p></o:p> <o:p> </o:p> BlockClosure >> valueUninterruptably<o:p></o:p> ^ self ifCurtailed: [^ self]<o:p></o:p> <o:p> </o:p> At the moment however, Squeak and Pharo suffer a horrible damage to the image if you try:<o:p></o:p> <o:p> </o:p> [ self error ] valueUninterruptably<o:p></o:p> <o:p> </o:p> and later e.g.:<o:p></o:p> <o:p> </o:p> Semaphore new waitTimeoutMSecs: 50<o:p></o:p> <o:p> </o:p> The worst part is the user won't notice anything and a simple code will run as if nothing happened - until an error or a crash happens. One of only a few ways to see something's off is e.g. Squeak's `Processor activeProcess = Project current uiProcess` which all of a sudden answers false (!)<o:p></o:p> <o:p> </o:p> But that's just Squeak/Pharo; Cuis is not affected as badly because it doesn't use the `effectiveProcess` mechanism.<o:p></o:p> <o:p> </o:p> Martin McClure also mentioned #valueUnpreemptively; funny thing is it doesn't work as designed because there's a bug in Process>>#priority which will leave the elevated process run at highest priority until it reaches a suspension point instead of bumping the priority back lower before returning from #valueUnpreemptively. It's discussed in this thread: <a class="moz-txt-link-freetext" href="http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126982.html">http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126982.html</a> . The conclusion is a new primitive for #priority is needed. <o:p></o:p> <o:p> </o:p> ><o:p> </o:p> > I also tried all your tests and examples. They cover a really broad and exhaustive set of scenarios! A few comments:<o:p></o:p> > - Many examples don't work in Cuis, because we made #fork answer nil (and not the forked process). The reason for this is explained in the comment in #fork. The pattern is instead of "p := [stuff] fork." do "p := [stuff] newProcess. p resume." With this change, all the examples work as expected.<o:p></o:p> <o:p> </o:p> Oops, apologies, I noticed the fork pattern (very reasonable), I modified my #fork to return the process to avoid the need to modify all the examples I created for Squeak :) Same for 'self error' unfortunately - for Cuis <o:p></o:p> <o:p> </o:p> self error <o:p></o:p> <o:p> </o:p> in the examples has to change to: <o:p></o:p> <o:p> </o:p> self error: 'unwind error'<o:p></o:p> <o:p> </o:p> sorry... <o:p></o:p> <o:p> </o:p> <o:p> </o:p> > - The notes for a few examples speak of crashes in Cuis. I pushed some fixes a few days ago, and now cmd-. works as expected. The examples behave the same as in Squeak. Please pull your repos.<o:p></o:p> ><o:p> </o:p> <o:p> </o:p> I will, thanks!<o:p></o:p> <o:p> </o:p> <o:p> </o:p> > Additionally, this remark of you (Jaromir) I don't understand:<o:p></o:p> > /////<o:p></o:p> > ad 1) The #isTerminated condition `suspendedContext pc > suspendedContext startpc` is always met after executing the first instruction of the bottom context – generally not a sign of a terminated process.<o:p></o:p> > \\\\\\<o:p></o:p> > I don't see that condition neither in Squeak (#19435) nor Cuis (#4567).<o:p></o:p> ><o:p> </o:p> <o:p> </o:p> My bad explaining; I was talking about #isTerminated implementation in Cuis (and Pharo) using this old condition - on the last line of:<o:p></o:p> <o:p> </o:p> Process >> isTerminated<o:p></o:p> "Answer true if terminated, i.e. can never be resumed again, because have nothing to run."<o:p></o:p> self isRunning ifTrue: [^ false].<o:p></o:p> ^suspendedContext isNil<o:p></o:p> or: [ suspendedContext pc isNil<o:p></o:p> or: ["If the suspendedContext is the bottomContext it is the block in Process>>newProcess.<o:p></o:p> If so, and the pc is greater than the startpc, the bock has alrteady sent and returned<o:p></o:p> from value and there is nothing more to do."<o:p></o:p> suspendedContext isBottomContext<o:p></o:p> and: [<o:p></o:p> suspendedContext pc > suspendedContext startpc]]]<o:p></o:p> <o:p> </o:p> Squeak improved this condition a while ago but it's still insufficient :) It's discussed here: <a class="moz-txt-link-freetext" href="http://forum.world.st/The-Inbox-Kernel-jar-1376-mcz-tp5127335p5127341.html">http://forum.world.st/The-Inbox-Kernel-jar-1376-mcz-tp5127335p5127341.html</a><o:p></o:p> <o:p> </o:p> <o:p> </o:p> > In any case, I think this is a great contribution, It perfectly fixes a lot of broken behavior, and doesn't seem to bring problems. I'm all for integrating it.<o:p></o:p> ><o:p> </o:p> > Jaromir, do you intend to turn the rest of your examples into tests? I think we should also do that, so we integrate all your experiments and what you learnt.<o:p></o:p> ><o:p> </o:p> <o:p> </o:p> I'd love to but I realized I don't know how to build tests involving raising errors and pressing Abandon on the Debugger :D If you could point me in the right direction it'd save me a lot of trying :) <o:p></o:p> <o:p> </o:p> Thanks a lot for all your comments. I'm happy you like the suggestion and would be delighted to see it integrated. <o:p></o:p> <o:p> </o:p> > Thanks!<o:p></o:p> ><o:p> </o:p> <o:p> </o:p> Best regards,<o:p></o:p> <o:p> </o:p> Jaromir<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </blockquote> <pre class="moz-signature" cols="72">-- Juan Vuletich <a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a> <a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a> <a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a> <a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a> @JuanVuletich</pre> </body> </html>