Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!atux01!perry
From: perry@atux01.UUCP (P. Kivolowitz)
Newsgroups: comp.sys.amiga
Subject: Re: Note on Interactive task priority implementation
Message-ID: <475@atux01.UUCP>
Date: Fri, 26-Jun-87 00:36:47 EDT
Article-I.D.: atux01.475
Posted: Fri Jun 26 00:36:47 1987
Date-Received: Sat, 27-Jun-87 04:56:06 EDT
References: <8706251111.AA08860@cogsci.berkeley.edu>
Organization: AT&T CSEd/CET, Piscataway, N.J.
Lines: 30
Summary: Un*x style sliding priorities apply here

In article <8706251111.AA08860@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes:
> > Ideally the system would have a provision for a special task bit
> > of "INTERACTIVE".  A interactive task would receive the processor before
> My canidate for this bit would be in Intuition's window and screen
> structures.  A strange place until you consider that Intuition knows

This seems kludgey. The way the Un*x operating system handles this is
elegant in that the desired effect (keeping interactive processes  at
interactive priorities) is a by product of the Un*x scheduling  algo-
rithm. In short:

The more you execute the lower your priority
    The lower your priority the less you execute
        The less you execute the more your priority
            The more your priority the more you execute
                The more you execute the lower your priority (and loop)

Interactive processes spend most of their time interacting and therefore
naturally float  at  the  highest  range of priorities available to user
processes.

Simply adding bits is not the way to go about modifying one's scheduler.
I personally think that the Amiga's exec has too simple a scheduler  and
might benefit from being completely rethought.

As usual, simple problems do not have simple answers.

Perry S. Kivolowitz
ASDG Incorporated
(201) 563-0529