Posted by
Jaromir Matas on
May 17, 2021; 10:00pm
URL: https://forum.world.st/The-semantics-of-halfway-executed-unwind-contexts-during-process-termination-tp5129800p5129817.html
Hi Christoph,
> IMHO, when terminating a process, halfway-executed unwinded contexts
> should not be continued. Only not-yet-activated unwind contexts should be
> triggered.
Yes, I too was wondering why there are different unwind semantics in various
situations (error handling, active process unwind, active and suspended
process termination); why there's not just one common semantics for all. My
conclusion was completing half-ways through unwind blocks was way more
complex than unwinding just the not-yet-started unwind blocks.
As a result (my opinion) Squeak implemented just the completion of the most
recent half-ways through unwind block during termination, and VisualWorks
went a step further and implemented the completion of the outer-most
half-ways through unwind block.
Both however left the termination of the active process on the basic level -
no completion of half-ways through blocks. In my attempt I proposed to unify
the semantics of active process and suspended process termination by
suspending the active process and terminating is as a suspended process.
I was considering a fun discussion about extending the error handling and
unwind semantics to match the termination unwind semantics - i.e. including
completion of half-ways through unwind blocks during normal returns - but
that's most likely in the "way too clever" territory :)
Your proposition goes in the opposite direction however - to reduce the
termination semantics to match the current error handling and active process
unwind semantics.
Well, I personally prefer completing the half-ways through unwind blocks
where possible. In my mind it means "try to repair or clean-up as much as
possible before ending a process". I still think completing half-ways
through unwind blocks is worth the extra effort.
Regarding the example:
> [
> [
> [
> [ ] ensure: [ "halfway through completion"
> [ ] ensure: [ "halfway through completion"
> self error.
> x1 := true].
> x2 := true]
> ] ensure: [ "not started yet"
> x3 := true]
> ] on: Error do: []
> ] fork
> {x1 . x2 . x3} ---> #(nil nil true)
>
> 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.
I disagree here: If we would not catch the error, we would be in a different
situation: an error would have occurred which we would not have anticipated,
thus abandoning the debugger would be a different intentional action than a
controlled and anticipated return from an exception. I may argue we could
even attempt to unwind as if terminating but I'm not sure it'd be justified.
So actually I must admit a different semantics here may even be desirable.
I'm not sure in this regard.
So to conclude, unification was my original driver but I'm no longer so
sure... Termination may be a different beast than a regular return or
handled error after all.
Thanks for this discussion, I look forward to taking a closer look at your
changeset!
Hi Nicolas,
Nicolas Cellier wrote
> 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.
Yes indeed, trying to be too clever is very dangerous!! I'm old enough to
know first hand :D
Thanks,
best,
-----
^[^ Jaromir
--
Sent from:
http://forum.world.st/Squeak-Dev-f45488.html
^[^ Jaromir