On 9/10/2010 9:16 AM, Florin Mateoc wrote:
> The debugger is different in the sense that, while it does take over as the activeController upon its open, it only wants to suspend the previously running activeControllerProcess in those cases when
> the previously running activeControllerProcess is the process under debug
Sorry about all these self-replies. I just wanted to make one more edit before I run to work, because I think it is
important documentation:


What we want to make sure, in the general case, is not so much that we kill the active process but the currently running
activeControllerProcess, and allow the newly created controller loop to become the new activeControllerProcess. We want
to make sure that one and only one controller (or screen) loop (ui process) runs at all times (except very briefly
during transitions from one ui process to the other).

The debugger is different in the sense that, while it does take over as the activeController upon its open, in those
cases when the currently running activeControllerProcess is the process under debug, it only wants to suspend it.
It does want to terminate the currently running activeControllerProcess otherwise (then the debugger behaves like any
other "normal" ui controller).

There are probably many different ways to achieve this. E.g. a lot of these scheduling methods in VW are guarded with a
"activeControllerProcess notNil and: [activeControllerProcess == Processor activeProcess]". The same check is constantly
done in the controller loop. Squeak doesn't have these checks, so it works with a lot of assumptions about which methods
are called from which processes


Florin