I think I've got it.  This message is to confirm my understanding and
answer a few questions people asked me.

When Tim originally wrote
> There is a single active process and it runs until it stops. You can
> make it stop temporarily by deliberately yielding occasioanlly
this was a reference to the scenario where the active process had
priority greater than or equal to any runnable process.  Further, the
deliberate yielding is only important for same-priority processes;
higher priority processes will run anyway, and lower priority
processes still won't run even if you attempt to yield to them (using
Processor yield--if you use a Delay or something else that actually
stops the current process, lower priority processess will get a chance
as long as no higher priority processes are runnable).

Originally I thought this meant that any process would run until it
stopped and would not give up control under any circumstances.

On Mon, Mar 28, 2005 at 09:28:24PM -0800, Tim Rowledge wrote:
> Ross Boylan <RossBoylan at stanfordalumni.org> wrote:
> 
> >
> > 
> > I thought from earlier remarks (not by you) that even a lower priority
> > process could block a higher priority process, if the former did not
> > yield control.
> Higher priority processes that are in a runnablestate (ie not held back
> by a semaphore etc) will take control away from any lower priority
> process just as soon as they can. As John said, that opportunity comes
> with every message send and backwards branch bytecode, which is quite
> frequently. However, if a low priority process calls a very long
> running prim (right now any DNS related activity counts as a
> geologically long prim on my setup; damn telus DNS...) then you can be
> held up for a while. VW has some mechanism for combating this by ...
> well some means or other involving native threads. 
> 

So John's  earlier statement that
> [P]rocessing switching can occur ....
> on a primitive call if  when the call takes > 1 or perhaps 17ms  
> depending on platform.
does not reflect current behavior?

> > 
> > Obviously if you have a lower priority (smalltalk) process a higher
> > priority process can block you, but I thought the problems did not end
> > there.  Most of the comments in this email thread indicate that the
> > initial example of the email thread was a problem only because it was
> > running at a relatively high priority.  But some of the comments
> > indicate the problem is the processor (as in processor vs email, not
> > as in the class Processor) thread is not yielding control,
> > regardless of its priority.
> Can't quite make out your point there, sorry.

Sorry to be unclear (Ned also couldn't follow).  Rephrasing, it's
clear that higher priority processes can block lower priority ones.
But I read some of the comments (e.g., the quote from Tim at the top
of this message) as saying that a low priority process could block a
high priority one.  My current understanding is that's not true
(unless there's a call out or a weird bit of code without message
sends or jumps back).

> 
> [snip]
> > But below you say every method  send is an opportunity to yield, so
> > explicitly coded yields seem unnecessary.  More about this below.
> Recall that the process switch checking done in the VM only checks for
> a runnable _higher_ priority process.

This clarifies something for me: although the places in which a
process can yield occur frequently, yielding does *not* occur
automatically to same priority processes.  This would be one reason to
code explicit yields.

> Not for other equal or lower
> priority ones. Yielding is needed if you want to 'play nice' and give
> other same-priority processes a go at the cpu; #yield puts the current
> process at the back of the right priority list and gets the one now at the
> front. This gives a sort-of round robin effect. It does nothing at all to
> help starving low class processes. To give lower priorities a go you have to
> suspend anything higher - make them wait on a semaphore with a short delay for
> example.
> 
> I guess the good news is that pretty much everything is accessible and
> you could write a scheduler that would do pretty much anything you want
> by way of sharing the cpu out.
> 

Was the decision not to implement a scheduling policy with ageing
(priority drops as a process runs; it rises the longer it has not run)
motivated by a desire for simplicity, or by some actual risks with an
ageing policy?

P.S. Multiprocessor systems are becoming increasingly common. so that
would be one possible motivation for native threads.