Igor Stasenko wrote:
> Another improvement would be to marry the process termination with
> exception handling,
> and nicely signal ProcessTerminatedException.
> This offers many practical benefits, since then we could write:
> 
> [ ... ] on: ProcessTerminatedException do: [:ex |
>    "oh man we're been terminated"
> ].

A simpler and more robust alternative that I talked to Eliot about 
yesterday is to simply have another indirection for activeProcess, i.e.,

ProcessorScheduler>>activeProcess
   "Answers the currently active process"
   ^activeProcess currentProcess

Process>>currentProcess
   "If I am pretending to be another process, answer it.
   Otherwise answer self"
   currentProcess ifNil:[^self].
   "Pass the request on since we could be debugging unwind issues"
   ^currentProcess currentProcess

Why is this advantageous? Several reasons:

a) It is not only useful for termination, but also for debugging. The 
debugger can provide the currently suspended process and simulated code 
will pick up the "right" identity (as the above illustrates this way you 
would be able to debug unwind blocks and have the code pick up the 
bindings from the process being terminated in the debugger :)

b) There is no question about either priority, what the terminated 
process status is when exiting #terminate etc. as it is within the 
calling process execution context (otherwise the terminating process 
might never complete if it has a low priority).

c) It rules out a whole class of errors that can happen if you rely on 
exception handling being implemented "correctly" in the users code. For 
example, there are several places that handle Exception instead of 
Error, Halt (or whatever they really should handle). Handling 
ProcessTermination "accidentally" is obviously error prone and I don't 
think user code should have a choice of handling it (there are perfectly 
good ways to implement such a feature yourself if you really need it and 
there is no good reason for user code by default to deny termination; 
not even accidentally).

d) Error handling occurs in the calling process. That's important 
because often termination is something done as a last resort and it is 
not unusal to have different error handlers when you terminate a process 
compared to the error handlers that you need when you run it normally.

Cheers,
   - Andreas