Hi Jaromir,<br>
<br>
back from vacation, *finally* I have found some time to return back to this pleasant problem! :-)<br>
<br>
Great, it sounds like we're already agreeing pretty much, just let me address some small points:<br>
<br>
> Debugger - Abandon could be the lightweight version you proposed. Why not<br>
> have a proper Abandon button for it?<br>
>     The right click menu on a context could offer the Kill option (next to<br>
> 'peel to first like this'); no button necessary.<br>
>     Now the question is what should be under the "window close" red-circle-x -<br>
> heavyweight terminate? I'm thinking this scenario: if the debugger returns<br>
> after closing the window you start thinking what happened and use Abandon;<br>
> if it still doesn't help you go right-click and kill it?<br>
> <br>
> My usual scenario is (limited experience however): look at something in the<br>
> debugger (on a healthy process) and close the window (i.e. full termination<br>
> is appropriate and I'd even say preferable). If something goes wrong - then<br>
> I'd welcome a hint there are options - thus the proper Abandon button - what<br>
> do you think? <br>
<br>
Hm, I would rather say that closing the window should have the same effect as pressing "abandon" - personally, I am very much used to this and we do not really have good options to communicate a different behavior of the close button. I think presenting the new behaviors Kill (i) and (iii) in some kind of menu would be less confusing.<br>
A kill item in the stack trace menu sounds fine for now (even though killing is not actually related to the selected context). In the long term, I would like to introduce menu buttons in the fashion of [1] in the Morphic UI (Marcel is currently reviewing my proposal for this), then we could move Kill into the Abandon menu, but for now, your proposal sounds perfectly fine to me. :-)<br>
<br>
> look at something in the debugger (on a healthy process) and close the window (i.e. full termination is appropriate and I'd even say preferable).<br>
<br>
Can you help me please, if the process is healthy (so no unwind context is lying on the stack), would there be any difference between the different terminate modi (ii) and (iii)?<br>
<br>
> > But I don't have any good idea for version (ii) yet. Call it #abandon like<br>
> > in the debugger? Then again, #abandon is rather a verb from the Morphic<br>
> > language. Further possible vocables (according to my synonym thesaurus)<br>
> > include #end, #stop, #finish, #unwind, #abort, #exit. Please help... :-)<br>
> <br>
> I'd probably go with something like #terminateLight because it's a proper<br>
> process termination including unwinds except the ones currently in progress<br>
> - so it is a light version of #terminate :) I've checked VisualWorks: they<br>
> chose #terminateUnsafely for this type of termination which I don't like<br>
> much, it sounds too negative; the real meaning is rather<br>
> #terminateAsSafelyAsPossibleGivenTheCircumstances ;).<br>
<br>
Hm, "light" reminds me of "friendly" and (iii) would certainly be more friendly (giving the process more freedom for cleaning things up). Difficult ...<br>
What about #terminateNow for (ii) and #terminate for (iii), slightly related to #updateStyle and #updateStyleNow? Since (iii) might continue with the execution of the current halfway-executed context, (ii) is more urgent.<br>
Another option would be "terminate: aggressive", analogously to "cleanup: aggressive" on Behavior where #terminate would fall back to "terminate: false". But this would make the new mode a little bit worse accessible.<br>
<br>
Concerning your #unwindTo: issue - not sure if this actually related to this thread? Actually I've lost the overview which terminate mode - (ii) or (iii) - you are referring to, maybe we should discuss this in a separate conversation. :-)<br>
<br>
---<br>
<br>
TLDR: Concerning our next steps - consider this a small to-do list:<br>
<br>
- [ ] We want to implement three modi of process termination:<br>
  - [ ] (i) is not yet implemented but should be easy to implement<br>
  - [ ] (ii) is in my proposal from [2], maybe needs further refinement<br>
  - [ ] (iii) is pretty much what we have in Process >> #terminate in the current Trunk. Is there anything still missing yet?<br>
- [ ] Decide on names for (ii) and (iii) - see above<br>
- [ ] Decide on UI integration into debugger - see above<br>
<br>
Further answers following soon.<br>
<br>
Best,<br>
Christoph<br>
<br>
[1] https://user-images.githubusercontent.com/48567372/60924070-4472fe80-a26e-11e9-9e61-5c167bc31e9b.png<br>
[2]<br>
http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215608.html (fix-Process-terminate.cs)<br>
<br>
<font color="#808080">---<br>
</font><i><font color="#808080">Sent from </font></i><i><u><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><font color="#808080">Squeak Inbox Talk</font></a></u></i><br>
<br>
On 2021-05-29T14:31:13-05:00, m@jaromir.net wrote:<br>
<br>
> Hi Christoph,<br>
> <br>
> > Jaromir, your proposal to provide multiple selectors for modeling separate<br>
> > modes of termination sounds like a very good idea to me. But how many<br>
> > different modes do we actually need? So far I can count three modes:<br>
> ><br>
> > (i) run no unwind contexts (harshest possible way; currently only<br>
> > achievable by doing "suspendedContext privSender: nil" prior to<br>
> > terminating)<br>
> > (ii) run not-yet started unwind contexts (this is what I proposed in<br>
> > fix-Process-terminate.1.cs [1])<br>
> > (iii) run all unwind contexts, including those that already have been<br>
> > started (this is the most friendly way that you implemented in #terminate<br>
> > recently)<br>
> <br>
> I think this is it.<br>
> <br>
> Litereally minutes ago had to use privSender: nil to get rid of a debugger<br>
> :) Fully terminate really is too strong to recover from fatal errors.<br>
> <br>
> > ... my point here is: Proceeding from an error almost always doesn't seem<br>
> > "right". :-) It is always a decision by the debugging programmer to<br>
> > override the default control flow and switch to the "next plausible<br>
> > alternative control flow", i.e., resume as if the error would have never<br>
> > been raised. <br>
> <br>
> yes - I'd add: even an error may quite often be completely benign, like<br>
> 'Transcript show: 1/0' - possibly a typo so you just may want to Proceed or<br>
> fully terminate. In case the error damages a whole subsequent chain of<br>
> events, you're absolutely right a full termination seems a silly option and<br>
> a light version of terminate may be the most appropriate. <br>
> <br>
> So I fully agree the decision which termination mode it is stays with the<br>
> user - so I'm all for giving the user the choices you suggested.<br>
> <br>
> > \1. Which mode should we use in which situations?<br>
> ><br>
> > I think this debate could benefit from a few more concrete usage<br>
> > scenarios. I'm just collecting some here (thinking aloud):<br>
> ><br>
> > \- Process Browser: We can provide multiple options in the process menu.<br>
> > \- Debugger: I agree with you that Abandon should always run not-yet<br>
> > started unwind contexts but never resume halfway-executed unwind contexts.<br>
> > So this maps to to mode (ii) from above.<br>
> > \- Skimming through most senders of #terminate in the image, they often<br>
> > orchestrate helper processes, deal with unhandled errors or timeouts, or<br>
> > do similar stuff - usually they should be very fine with the friendly<br>
> > version of #terminate, i.e. mode (iii) from above. I think.<br>
> > \- Regarding option (1), I think you would need it extremely seldom but<br>
> > maybe in situations like when your stack contains a loop, your unwind<br>
> > contexts will cause a recursion/new error, or you deliberately want to<br>
> > prevent any unwind context from running. No objections against adding a<br>
> > small but decent button for this in the debugger. :-)<br>
> ><br>
> > Would you agree with these behaviors? Maybe you can add further examples<br>
> > to the list?<br>
> <br>
> Yes<br>
> <br>
> Process Browser - the right click menu could provide all options<br>
> <br>
> Debugger - Abandon could be the lightweight version you proposed. Why not<br>
> have a proper Abandon button for it?<br>
>     The right click menu on a context could offer the Kill option (next to<br>
> 'peel to first like this'); no button necessary.<br>
>     Now the question is what should be under the "window close" red-circle-x -<br>
> heavyweight terminate? I'm thinking this scenario: if the debugger returns<br>
> after closing the window you start thinking what happened and use Abandon;<br>
> if it still doesn't help you go right-click and kill it?<br>
> <br>
> My usual scenario is (limited experience however): look at something in the<br>
> debugger (on a healthy process) and close the window (i.e. full termination<br>
> is appropriate and I'd even say preferable). If something goes wrong - then<br>
> I'd welcome a hint there are options - thus the proper Abandon button - what<br>
> do you think? <br>
> <br>
> > \2. How should we name them?<br>
> ><br>
> > Direct proposal: (i) #kill and (iii) #terminate.<br>
> > After looking up the original behavior of #terminate in Squeak 5.3, I<br>
> > think it would be consistent to resume all halfway-executed unwind<br>
> > contexts in this method. So yes, I also withdraw my criticism about<br>
> > #testNestedUnwind. :-)<br>
> ><br>
> > But I don't have any good idea for version (ii) yet. Call it #abandon like<br>
> > in the debugger? Then again, #abandon is rather a verb from the Morphic<br>
> > language. Further possible vocables (according to my synonym thesaurus)<br>
> > include #end, #stop, #finish, #unwind, #abort, #exit. Please help... :-)<br>
> <br>
> I'd probably go with something like #terminateLight because it's a proper<br>
> process termination including unwinds except the ones currently in progress<br>
> - so it is a light version of #terminate :) I've checked VisualWorks: they<br>
> chose #terminateUnsafely for this type of termination which I don't like<br>
> much, it sounds too negative; the real meaning is rather<br>
> #terminateAsSafelyAsPossibleGivenTheCircumstances ;).<br>
> <br>
> I'm wondering whether #unwindTo: (used ony by Generator) is bugged (with<br>
> regard to dealing with non-local returns), and could be fixed/unified with<br>
> your approach. Look at these examples:<br>
> ```<br>
> p := [[Processor activeProcess suspend] valueUninterruptably] fork.<br>
> Processor yield.<br>
> p suspendedContext unwindTo: nil<br>
> ```<br>
> or<br>
> ```<br>
> p := [[:exit | [Processor activeProcess suspend] ensure: [exit value]]<br>
> valueWithExit] fork.<br>
> Processor yield.<br>
> p suspendedContext unwindTo: nil<br>
> ```<br>
> <br>
> If you do `p terminate` instead of `p suspendedContext unwindTo: nil`, it<br>
> works fine, but #unwindTo causes a block cannot return error - I think it's<br>
> the same bug all over again :) #value evaluates the non-local return on the<br>
> wrong stack...<br>
> <br>
> <br>
> <br>
> Regarding our cannot return discussion - I have to think about it and I'll<br>
> post my reply later in [1] to keep it separate :)<br>
> <br>
> Thanks again and regards,<br>
> <br>
> [1]<br>
> http://forum.world.st/The-Inbox-Kernel-ct-1405-mcz-td5129706.html#a5130114<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> -----<br>
> ^[^ Jaromir<br>
> --<br>
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html<br>
> <br>