I've not *found* any bugs in the scheduler, as long as you remember 
that:

- Higher-priority processes pre-empt lower-priority processes;

- Processes at the same priority do not pre-empt each other;

- A loop that forks processes that run at a higher priority than the 
  loop's process may never complete, as it may fail to get enough 
  cycles to fork the remaining processes after the first (a swift test 
  would be to increment an instance variable in the loop, and see how 
  many you actually get).

Exactly. Squeak does do pre-emptive scheduling but does not pre-empt 
within a priority level. When a higher level procees pre-empts, the 
lower process is stuck at the end of the queue of processes waiting 
for time at that priority. Thus you can implement round-robin 
scheduling quite effectively with a Delay in a loop in a high priority 
process. Implementing a scheduler that makes all processes get some 
time depending upon their priority would be a modest extension left as 
an exercise for the student.

> At the moment I'm just annoyed
> that my low priority processes (I assume 10 is low and 80 is high...)
> can lock up Squeak. With my 10-process test that I posted,
> Squeak will
> respond to a alt-., but sluggishly if at all. Theoretically it
> shouldn't, but it does.

Ah, now I seem to recall that's a different problem.  In order to keep 
the speed of bytecode execution high, I recall that not all bytecodes 
check for possible context switches *at all*.  There's then a timer in 
the VM that triggers much more rarely and forces a check, just in case 
of a tight loop that blocks the UI.  Tight loops tend to produce 
bytecode sequences that don't trigger checks, as I recall.  Real-life 
code wouldn't cause the same problems.