On Apr 13, 2010, at 2:18 PM, Chris Muller wrote:

> On Tue, Apr 13, 2010 at 2:53 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> 
>> 
>> On Tue, Apr 13, 2010 at 12:05 PM, Chris Muller <asqueaker at gmail.com> wrote:
>>> 
>>> Hi, I'm not very well-versed in process-scheduling, but I'm having
>>> trouble understanding why you don't like sending the last pre-empted
>>> process to the back of its queue of processes waiting at that level.
>>> Doesn't that seem more "fair" and also, allow "smoother" multi-tasking
>>> since those other processes at that level would get a turn?
>>> 
>>> Your reason was:  "It means one cannot rely on cooperative scheduling
>>> within a priority level."  but I don't understand what you mean by
>>> "rely on"?
>> 
>> A cooperative scheduler is one in which it is guaranteed that another
>> process does not run until the active process chooses to yield.  This makes
>> it easy to implement particular forms of synchronisation because processes
>> are not preemptive.  The Smalltalk scheduler is a form of real-time
>> scheduler in which processes have fixed priorities and are only preempted by
>> higher-priroity processes.  This also makes it easy to implement various
>> kinds of multi-process behaviour because one is guaranteed that a
>> lower-priority process is never running while a higher priority process is
>> able to run.
> 
> Ok, I am guessing this is useful for time-critical applications; like
> a voip chat program.  So it can choose to not be interrupted while
> actively digitizing voice, perhaps..

If you have some task that is clearly higher-priority than some other task (eg: VoIP vs. polling an email server), then it's better to simply use a higher-priority Process rather than relying on particular scheduling behavior within a single priority-class.

Cheers,
Josh