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. 

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

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


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- The twinkle in his eyes is actually the sun
shining between his ears.