Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!COGSCI.BERKELEY.EDU!bryce
From: bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt)
Newsgroups: comp.sys.amiga
Subject: Re: Defense of multi-tasking response
Message-ID: <8708220211.AA24135@cogsci.berkeley.edu>
Date: Fri, 21-Aug-87 22:11:07 EDT
Article-I.D.: cogsci.8708220211.AA24135
Posted: Fri Aug 21 22:11:07 1987
Date-Received: Sun, 23-Aug-87 06:37:16 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Institute of Cognitive Studies, UC Berkeley
Lines: 35


In article <> barnett@steinmetz.UUCP (Bruce G Barnett) writes:
>In article <> denbeste@cc5.bbn.com.BBN.COM (Steven Den Beste) writes:
>
> At the risk of my soul :-), here is what I understand of UN*X's algorithm...
> [read the article for the description]
> ...So it should be obvious that:
>
>	Interactive tasks get high priority.

No, it should be clear that lightly used interactive tasks get high priority.
If your interactive task is a CPU hog, it will get a low priority.

Based on CPU usage, it is impossible to determine which task the user is
waiting for.  This is why my "Auto-pri" toy asks Intuition.  Intuition
is the Amiga's user interface; it knows.

Auto-pri's problem is that it sets the priority .5 too high :-).  I really
need to dig into the scheduler to make it work the way I want.
Oh, since so many of you asked... Auto-pri will be posted to the net when
it's ready.  (comp.{sources,binaries}.amiga)


>This provides `reasonable' sharing of resources, without the user
>writing any special `hooks' into the code.

On a single-user machine like the Amiga, on which you *know* which is the
interactive task, I contend that a hook is ok.  For a multi-user computer
I would not have the same opinion.

-----
|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . 
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	"Success leads to stagnation; stagnation leads to failure."