[squeak-dev] The semantics of halfway-executed unwind contexts during process termination

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Mon May 17 15:29:56 UTC 2021


Hi all, hi Jaromir,


I'm raising a new question in this post that is related to the following threads, but I think that it deserves its own thread due to the fundamental criticism expressed: [1, 2]

I just took a closer look at ProcessTest >> #testNestedUnwind and I have to say that I don't agree with it. I'm sorry that I did not mention this earlier, but somehow this aspect of Jaromir's large amount of recent work has escaped my attention before today. For reference, so that we all know what we are talking about, here is the test in question:


testNestedUnwind

"Test all nested unwind blocks are correctly unwound; all unwind blocks halfway through their execution should be completed or at least attempted to complete, not only the innermost one"


| p x1 x2 x3 |

x1 := x2 := x3 := false.

p :=

[

[

[ ] ensure: [ "halfway through completion when suspended"

[ ] ensure: [ "halfway through completion when suspended"

Processor activeProcess suspend.

x1 := true].

x2 := true]

] ensure: [ "not started yet when suspended"

x3 := true]

] fork.

Processor yield.

p terminate.

self assert: x1 & x2 & x3.

I'm not convinced about the assertions in this test. :-) In fact, I would only expect x3 to be true but x1 and x2 to be false!
IMHO, when terminating a process, halfway-executed unwinded contexts should not be continued. Only not-yet-activated unwind contexts should be triggered.
Here are my arguments:


  *   Regular unwinding and process termination should have exactly the same behavior.

Assume we manipulated the example from the test like this:
[
[
[
[ ] ensure: [ "halfway through completion when suspended"
[ ] ensure: [ "halfway through completion when suspended"
self error.
x1 := true].
x2 := true]
] ensure: [ "not started yet when suspended"
x3 := true]
] on: Error do: []
] fork.
I have highlighted the differences, so what I changed was i) to insert an error handler at the bottom of the process and ii) instead of terminating the process, to raise an error in the innermost block.
In this example, only x3 will be set to true which is because the exceptional control flow explicitly discontinues the logic running inside the error handler. Only not-yet-activated unwind contexts will be triggered as part of the unwinding, which only applies to the outermost unwind context.
In my view, process termination should have exactly the same semantics as using an exception to abort the control flow.
If we would not catch the error in the above example but press Abandon in the appearing debugger instead, I see no reason why we would want to execute a different set of unwind contexts.

  *   Last but not least, the fact that an error has been signaled means that the signalerContext is "infected" so under no circumstances, abandoning the process should resume the execution of this infected context! (The only exception is when you consciously do so via the "Proceed" button in a debugger.) This might become more vivid if I replace the innermost block with the following:

x1 := (2 / 0  "error!") > 0.
Actually, it is enough to run the following stand-alone:
[] ensure: [
x1 := (2 / 0  "error!") > 0
]
If you debug the Abandon button, you can see that another error occurs while terminating the process, which is a MessageNotUnderstood for #> in ZeroDivision. The only reason why a second debugger does not appear is the current bug in Process >> #terminate which "absorbs" subsequent error in this situation and which is currently being discussed in [2].

Sorry for the long message! I hope that you agree with my arguments, and if not, I am very excited to hear your ones. :-) Unless contradicted, I would like to request to change #testNestedUnwind as described above and use the changed version as the general basis for the ongoing discussions in [1, 2]. But maybe I am also just committing a fatal case of false reasoning ... :-)

Best,
Christoph

[1] http://forum.world.st/The-Inbox-Kernel-ct-1405-mcz-td5129706.html
[2] http://forum.world.st/stepping-over-non-local-return-in-a-protected-block-td5128777.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210517/95aaf14d/attachment.html>


More information about the Squeak-dev mailing list