Hi Christoph,
I guess that the original intention was to perform the cleanup (like
releasing resources) even if we close the debugger in the midst of
unwinding.
Whether this is a good idea or not is questionable indeed if the debugger
was opened due to unhandled error during execution of unwind block.
But the debugger was not necessarily opened during unwinding...
The question you raise is whether we are trying to be too much clever... It
might be.



Le lun. 17 mai 2021 à 17:30, Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> a écrit :

> 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/16b03a0e/attachment.html>