A lower priority process will chew all the available CPU but not really  
affect higher running processes.
higher priority cpu intensive processes are a different manner.

if you look at
Interpreter>>transferTo: aProc
"Record a process to be awoken on the next interpreter cycle.
is where process switching occurs.

that gets called on wait, suspend or resume.

A process can wait on a semapore or be suspended, resume occurs on an  
semaphore signal waking up another process,
however which process runs is based on newPriority > activePriority. So  
even if a lower priority process gets a semaphore signal
it won't run if a higher priority process is running. Note that Morphic  
is checking for events every 1/60 of a second or so, it it causes a  
resume to occur based on checkForInterrupts noticing the clock and time  
passing, which it does every 1-3ms depending on the platform.

Interpreter>>checkForInterrupts also has some logic for lowspace etc to  
signal a semaphore, thus causing a resume

If you do "ProcessBrowser open" you can see the running processes.

In a basic image I've:
80 (the timer interrupt watcher, its responsible for handling clock  
wraps & logic for Delay)
60 (the user interrupt watcher, he's waiting for a command key  
combination to invoke the debugger)
60 (the I/O process, he's responsible for fetch events from the VM  
event queue and dispatching)
60 (the low space watcher, he's responsible for yelling at you if space  
is low).
40 (the UI process, he's morphic events etc)
10 (the idle process, he sleeps/naps the OS thread to reduce Squeak CPU  
usage if Squeak is idle)

Priorities you grab from Processor are based on class variable values  
which are:

SystemRockBottomPriority _ 10.
SystemBackgroundPriority _ 20.
UserBackgroundPriority _ 30.
UserSchedulingPriority _ 40.
UserInterruptPriority _ 50.
LowIOPriority _ 60.
HighIOPriority _ 70.
TimingPriority _ 80.

In practice if you fork off tasks at UserBackgroundPriority (30), then  
you can always gain control and terminate a wild one.
Fork one off at 60, then you'll need to kill the VM and restore your  
state via the change log...

"...is because processes are partially preemptive. A running process
will not be interrupted by another process of equal or lesser priority.
A process will keep running until it does a time consuming operation
such as waiting on a socket read or on an instance of Delay, or the
process explicitly gives up control, or a higher priority process is
ready to run."

So basically - if you have a Process running at a higher prio it will
preempt the lower ones. And using ProcessorBrowser (drag one out from
the right flap) you can "start CPU watcher" which is really good when
developing using Processes - otherwise you can pretty easily end up in a
tight little knot...

Btw, really cool Stephane with the free books!

regards, Göran

PS. Plug: SharedStreams are pretty nifty - haven't heard anyone using
them yet but they work like stream "pipes" between Processes. Like
SharedQueue for characters but without the bugs. ;-) Check the class
comments and class side examples. Very useful when doing Socket stuff
using multiple Processes. :-)