[Cuis-dev] Unwind mechanism during termination is broken and inconsistent

Juan Vuletich juan at jvuletich.org
Wed Apr 14 09:08:35 PDT 2021


Hi Jaromir,

On 4/14/2021 5:37 AM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan, hi all,
>
> I’m enclosing an amended list of examples with fixed #fork and ‘self 
> error’ patterns so that you can use them right away.
>

Thanks!

> > - 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.
>
> Yes, it’s perfect :) I removed the crash notes from the example list.
>

Thanks.

> 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).
>
> The Squeak semantics of #valueUninterruptably is “don’t let anything 
> kill me” (using a non-local return in the unwind block).
>

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

> Best regards,
>
> Jaromir
>

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,

> *From: *Jaromir Matas via Cuis-dev <mailto:cuis-dev at lists.cuis.st>
> *Sent: *Wednesday, April 14, 2021 0:20
> *To: *Juan Vuletich <mailto:juan at jvuletich.org>; Discussion of Cuis 
> Smalltalk <mailto:cuis-dev at lists.cuis.st>
> *Cc: *Jaromir Matas <mailto:mail at jaromir.net>; Hernan Wilkinson 
> <mailto:hernan.wilkinson at 10pines.com>
> *Subject: *Re: [Cuis-dev] Unwind mechanism during termination is 
> broken and inconsistent
>
> Hi Juan,
>
> >
>
> > Hi Jaromir, hi all,
>
> >
>
> > This is a most impressive work!
>
> Many thanks for your encouragement - I'm really glad you like it :)
>
> >
>
> > It made me remember this talk given by Martin McClure in Smalltalks 
> 2019: https://www.youtube.com/watch?v=AvM5YrjK9AE . 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.
>
> 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 :)
>
> 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).
>
> BlockClosure >> valueUninterruptably
>
>                ^ self ifCurtailed: [^ self]
>
> At the moment however, Squeak and Pharo suffer a horrible damage to 
> the image if you try:
>
>                [ self error ] valueUninterruptably
>
> and later e.g.:
>
>                Semaphore new waitTimeoutMSecs: 50
>
> 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 (!)
>
> But that's just Squeak/Pharo; Cuis is not affected as badly because it 
> doesn't use the `effectiveProcess` mechanism.
>
> 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: 
> http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126982.html 
> . The conclusion is a new primitive for #priority is needed.
>
> >
>
> > I also tried all your tests and examples. They cover a really broad 
> and exhaustive set of scenarios! A few comments:
>
> > - 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.
>
> 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
>
>                self error
>
> in the examples has to change to:
>
>                self error: 'unwind error'
>
> sorry...
>
> > - 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.
>
> >
>
> I will, thanks!
>
> > Additionally, this remark of you (Jaromir) I don't understand:
>
> > /////
>
> > 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.
>
> > \\\\\\
>
> > I don't see that condition neither in Squeak (#19435) nor Cuis (#4567).
>
> >
>
> My bad explaining; I was talking about #isTerminated implementation in 
> Cuis (and Pharo) using this old condition - on the last line of:
>
> Process >> isTerminated
>
>                "Answer true if terminated, i.e. can never be resumed 
> again, because have nothing to run."
>
>                self isRunning ifTrue: [^ false].
>
>                ^suspendedContext isNil
>
>                               or: [ suspendedContext pc isNil
>
>                                              or: ["If the 
> suspendedContext is the bottomContext it is the block in 
> Process>>newProcess.
>
>                                                             If so, and 
> the pc is greater than the startpc, the bock has alrteady sent and 
> returned
>
>                                                             from value 
> and there is nothing more to do."
>
>                                                             
> suspendedContext isBottomContext
>
>                                                                            
> and: [
>
>                                                                                           
> suspendedContext pc > suspendedContext startpc]]]
>
> Squeak improved this condition a while ago but it's still insufficient 
> :) It's discussed here: 
> http://forum.world.st/The-Inbox-Kernel-jar-1376-mcz-tp5127335p5127341.html
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> 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 :)
>
> Thanks a lot for all your comments. I'm happy you like the suggestion 
> and would be delighted to see it integrated.
>
> > Thanks!
>
> >
>
> Best regards,
>
> Jaromir
>


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210414/2c150fb8/attachment-0001.htm>


More information about the Cuis-dev mailing list