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...

On Tuesday, November 26, 2002, at 11:18  PM, Martin Drautzburg wrote:

> Ned Konz <ned at bike-nomad.com> writes:
>
>> [ something doSomethingVeryTimeConsuming ] forkAt: Processor
>> userBackgroundPriority.
>
> I always wondered: is this preemtive ? I mean can a process run into a
> loop and lock the system preventing any other process to run or will
> it just eat up CPU and slow down the system ?
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===