Hi Christoph,

> 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 (harshest 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)

I think this is it.

Litereally minutes ago had to use privSender: nil to get rid of a debugger
:) Fully terminate really is too strong to recover from fatal errors.

> ... my point here is: Proceeding from an error almost always doesn't seem
> "right". :-) It is always a decision by the debugging programmer to
> override the default control flow and switch to the "next plausible
> alternative control flow", i.e., resume as if the error would have never
> been raised. 

yes - I'd add: even an error may quite often be completely benign, like
'Transcript show: 1/0' - possibly a typo so you just may want to Proceed or
fully terminate. In case the error damages a whole subsequent chain of
events, you're absolutely right a full termination seems a silly option and
a light version of terminate may be the most appropriate. 

So I fully agree the decision which termination mode it is stays with the
user - so I'm all for giving the user the choices you suggested.

> \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?

Yes

Process Browser - the right click menu could provide all options

Debugger - Abandon could be the lightweight version you proposed. Why not
have a proper Abandon button for it?
	The right click menu on a context could offer the Kill option (next to
'peel to first like this'); no button necessary.
	Now the question is what should be under the "window close" red-circle-x -
heavyweight terminate? I'm thinking this scenario: if the debugger returns
after closing the window you start thinking what happened and use Abandon;
if it still doesn't help you go right-click and kill it?

My usual scenario is (limited experience however): 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). If something goes wrong - then
I'd welcome a hint there are options - thus the proper Abandon button - what
do you think? 

>  \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... :-)

I'd probably go with something like #terminateLight because it's a proper
process termination including unwinds except the ones currently in progress
- so it is a light version of #terminate :) I've checked VisualWorks: they
chose #terminateUnsafely for this type of termination which I don't like
much, it sounds too negative; the real meaning is rather
#terminateAsSafelyAsPossibleGivenTheCircumstances ;).

I'm wondering whether #unwindTo: (used ony by Generator) is bugged (with
regard to dealing with non-local returns), and could be fixed/unified with
your approach. Look at these examples:
```
p := [[Processor activeProcess suspend] valueUninterruptably] fork.
Processor yield.
p suspendedContext unwindTo: nil
```
or
```
p := [[:exit | [Processor activeProcess suspend] ensure: [exit value]]
valueWithExit] fork.
Processor yield.
p suspendedContext unwindTo: nil
```

If you do `p terminate` instead of `p suspendedContext unwindTo: nil`, it
works fine, but #unwindTo causes a block cannot return error - I think it's
the same bug all over again :) #value evaluates the non-local return on the
wrong stack...



Regarding our cannot return discussion - I have to think about it and I'll
post my reply later in [1] to keep it separate :)

Thanks again and regards,

[1]
http://forum.world.st/The-Inbox-Kernel-ct-1405-mcz-td5129706.html#a5130114







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