[squeak-dev] Solving multiple termination bugs - summary & proposal

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Sun Aug 22 14:49:10 UTC 2021


Hi Jaromir,

> Yes, I was wondering why I couldn't get rid of the duplication and now I think it's because there really are two distinct unwind semantics : one "light" for regular returns and one "heavy" for termination. Both are very similar yet each require a slightly different behavior - that's why the duality #runUntilErrorOrReturnFrom / #runUnwindUntilErrorOrReturnFrom or #complete: / #complete:to: and #unwindTo: / #terminate.

But they are still pretty similar ... Couldn't you just add some extra parameter to these message? E.g., "Context runUntilErrorOrReturnFrom: aggressive"? I have the feeling that we could eliminate significant duplication that way by inserting some ifs and elses ... Duplicated code very often tends to be harder to maintained.

> With regards to #unwindTo: - I haven't tested it yet but I'm wondering whether it wouldn't have the same unwind problem with non-local returns as the original #terminate and require a similar fix?

Hm, do we need to implement both modi - (ii) and (iii) as described in [1] - in Context >> #unwindTo: as well? Something like #unwindTo:aggressive:?

> But in general - yes, any method/exception purposefully (or not) written to create a loop will break this patch (I admit it is just a patch really). I extracted it to #complete:to: to make #terminate clean; this is a WIP; I wish there was a holistic solution to this - maybe checking for exception recursion by default? :)

Sounds better already, if feasible! But how would you detect this? Unfortunately I've lost track of these infinite loops - could you maybe point me to some concrete examples that lead to an infinite recursion without this special check? :-)

One more question about your #runUnwindUntilErrorOrReturnFrom: Are you maybe missing something like "cxt terminate" in the "No error was raised" case? Just wondering.

Best,
Christoph

[1] http://forum.world.st/The-semantics-of-halfway-executed-unwind-contexts-during-process-termination-tp5129800p5130110.html

---
Sent from Squeak Inbox Talk

On 2021-05-31T17:01:46-05:00, m at jaromir.net wrote:

> Jaromir Matas wrote
> > Hi All,
> > I've sent an updated version of #teminate integrating Christoph's solution
> > of BlockCannotReturn recursion problem (in [1]), along with a battery of
> > tests exploring termination of nested ensure and cascading errors behavior
> > (Debugger tests are for info and a final version can wait until releasing
> > Christoph's proposal in [2]).
> > 
> > It's pretty much final, I hope...
> > 
> > Any complaints about #terminate - please shout ;)
> > 
> > [1] http://forum.world.st/The-Inbox-Kernel-ct-1405-mcz-td5129706.html
> > [2]
> > http://forum.world.st/The-semantics-of-halfway-executed-unwind-contexts-during-process-termination-tp5129800p5130110.html
> > 
> > best,
> 
> Here's the link:
> http://forum.world.st/The-Inbox-Kernel-jar-1414-mcz-td5130198.html
> 
> 
> 
> -----
> ^[^ Jaromir
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210822/9adf7f0d/attachment.html>


More information about the Squeak-dev mailing list