[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