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

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Fri May 28 17:10:40 UTC 2021

Hi Jaromir, hi Nicolas,

thanks for your feedback. I think I see the conflict between useful clean-ups during termination on the one hand and way-too-clever clean-ups during abandoning an errored process on the other hand.

Jaromir, your proposal to provide multiple selectors for modeling separate modes of termination sounds like a very good idea to me. But how many different modes do we actually need? So far I can count three modes:

(i) run no unwind contexts (harhest possible way; currently only achievable by doing "suspendedContext privSender: nil" prior to terminating)
(ii) run not-yet started unwind contexts (this is what I proposed in fix-Process-terminate.1.cs [1])
(iii) run all unwind contexts, including those that already have been started (this is the most friendly way that you implemented in #terminate recently)

Can you please confirm whether this enumeration is correct and complete?

What seems disputable to me are the following questions:

1. Which mode should we use in which situations?

I think this debate could benefit from a few more concrete usage scenarios. I'm just collecting some here (thinking aloud):

- Process Browser: We can provide multiple options in the process menu.
- Debugger: I agree with you that Abandon should always run not-yet started unwind contexts but never resume halfway-executed unwind contexts. So this maps to to mode (ii) from above.
- Skimming through most senders of #terminate in the image, they often orchestrate helper processes, deal with unhandled errors or timeouts, or do similar stuff - usually they should be very fine with the friendly version of #terminate, i.e. mode (iii) from above. I think.
- Regarding option (1), I think you would need it extremely seldom but maybe in situations like when your stack contains a loop, your unwind contexts will cause a recursion/new error, or you deliberately want to prevent any unwind context from running. No objections against adding a small but decent button for this in the debugger. :-)

Would you agree with these behaviors? Maybe you can add further examples to the list?

2. How should we name them?

Direct proposal: (i) #kill and (iii) #terminate.
After looking up the original behavior of #terminate in Squeak 5.3, I think it would be consistent to resume all halfway-executed unwind contexts in this method. So yes, I also withdraw my criticism about #testNestedUnwind. :-)

But I don't have any good idea for version (ii) yet. Call it #abandon like in the debugger? Then again, #abandon is rather a verb from the Morphic language. Further possible vocables (according to my synonym thesaurus) include #end, #stop, #finish, #unwind, #abort, #exit. Please help... :-)


[1] http://forum.world.st/template/NamlServlet.jtp?macro=print_post&node=5129805

More information about the Squeak-dev mailing list