Hi Jaromir,


thanks a lot for your answer! Great to hear that you have found some other examples that would benefit from my patch as well. :-)


> A question: why not simply `ctxt restart`? Without assigning to suspendedContext. Like this:
>
> #terminate
>                 "... lots of code"
>                 ctxt := self popTo: suspendedContext bottomContext.
>                 ctxt == suspendedContext bottomContext ifFalse:
> >>>                 [ctxt restart.
>                         "self debug: ctxt title: 'Unwind error during termination'"].
>                 "Set the context to its endPC for the benefit of isTerminated."
>                 ctxt pc: ctxt endPC]

The "ctxt restart" was necessary to have the raised exception handled again after it has been absorbed by #runUntilErrorOrReturnFrom:.
I'm not sure about the exact semantics of suspendedContext, but shouldn't it always point to the latest context frame unless the process is running? Should we rather set suspendedContext to nil here?

That's another point I find questionary about my changeset - if the process refuses to terminate, it will be resumed again, even if it has been suspended before. Can or should we change that or is it already the most logical way (because every "unwinding" essentially means to "resume" the process anyway)?
Anyway, I think the method return after restarting the context is necessary because otherwise, its pc will be manipulated which we don't want unless the process has really been terminated.

#valueUninterruptably is also an interesting example. But this should also have been fixed using my proposal, shouldn't it? :-)

> Besides #isTerminated I've been trying to refactor #terminate and #newProcess to avoid 'cannot return' errors and unify different kinds of termination (active process termination and suspended process termination).

Nice work!

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jaromir Matas <m at jaromir.net>
Gesendet: Dienstag, 9. März 2021 10:54:02
An: squeak-dev at lists.squeakfoundation.org
Betreff: Re: [squeak-dev] Bug in Process>>#terminate | Returning from unwind contexts

Hi Christopher,

I've just been wondering what that part of #terminate was for... Thanks for
the answer :)

I tried a recursive version of your example and it behaves even worse:

   [self error: 'x1'] ensure: [[self error: 'x2'] ensure: [[[[self error:
'x3'] ensure: [^2]] ensure: [^2]] ensure: [^2]]]

And this one's bad too - hit Abandon and you get the unwind error right
away:

   [self error] ensure: [1/0]

After your fix/workaround they miraculously seem to behave again :)

A question: why not simply `ctxt restart`? Without assigning to
suspendedContext. Like this:

#terminate
                "... lots of code"
                ctxt := self popTo: suspendedContext bottomContext.
                ctxt == suspendedContext bottomContext ifFalse:
>>>                 [ctxt restart.
                        "self debug: ctxt title: 'Unwind error during termination'"].
                "Set the context to its endPC for the benefit of isTerminated."
                ctxt pc: ctxt endPC]


And finally, I noticed #valueUninterruptably uses return from an unwind
context as well and it doesn't seem to function properly due to the bug (ok
after your fix):

   [1/0] valueUninterruptably

First doit generates ZeroDivide, hit Abandon and the next doit shows unwind
error but Proceed will just end the process (I'd expect another ZeroDivide -
am I right?)

#valueUninterruptably
        "Prevent remote returns from escaping the sender.  Even attempts to
terminate (unwind) this process will be halted and the process will resume
here.  A terminate message is needed for every one of these in the sender
chain to get the entire process unwound."

        ^ self ifCurtailed: [^ self]


Besides #isTerminated I've been trying to refactor #terminate and
#newProcess to avoid 'cannot return' errors and unify different kinds of
termination (active process termination and suspended process termination).
I've sent it to the Inbox for discussion - see here:
http://forum.world.st/The-Inbox-Kernel-jar-1380-mcz-td5127524.html

Thanks,



-----
^[^ 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/20210309/518a09b0/attachment.html>