Posted by Jaromir Matas on May 19, 2021; 6:04pm
URL: https://forum.world.st/The-semantics-of-halfway-executed-unwind-contexts-during-process-termination-tp5129800p5129861.html

Hi Christoph,

I posted some additional arguments in
http://forum.world.st/Solving-multiple-termination-bugs-summary-proposal-tp5128285p5129859.html

> [...] 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!

This is what really got me thinking... yes, resuming errors sounds like a
bad idea. But the point is if you terminate a totally healthy process in the
middle of its unwind block then there's no reason to prevent its normal
completion. The thing is you don't know in advance. But a debugger is a
different story - you see an error and make a conscious decision - Proceed
or Abandon? That's why I was looking for a Kill button :) Currently the
consensus is Abandon = terminate, however this is not a given, it can be
reconsidered... e.g. use the unwind version of regular #return/#resume/ etc
- without unwinding halfway through block - that could make a good sense...

It means two different unwind semantics could really be desirable and
justified: If a healthy process terminates, let it unwind as much as
possible including all unwind blocks halfway-through execution.

If a broken process terminates via Abandoning the debugger, use the current
"return" unwind semantics - i.e. execute only not-yet-started unwind blocks.

What do you think?

I'm looking forward to your thoughts.
best,



-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html