Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!think!ames!ptsfa!ihnp4!chinet!steinmetz!jesup
From: jesup@steinmetz.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Optimize Multi-Tasking with this program.
Message-ID: <1446@steinmetz.steinmetz.UUCP>
Date: Tue, 14-Apr-87 16:45:16 EST
Article-I.D.: steinmet.1446
Posted: Tue Apr 14 16:45:16 1987
Date-Received: Fri, 17-Apr-87 03:24:09 EST
References: <3454@udenva.UUCP> <1657@husc6.UUCP>
Reply-To: jesup@kbsvax.steinmetz.UUCP (Randell Jesup)
Organization: General Electric CRD, Schenectady, NY
Lines: 24

In article <1657@husc6.UUCP> hadeishi@husc7.UUCP (Mitsuharu Hadeishi) writes:
>	"Optimizing" multi-tasking by raising the current input-active
>program to the highest priority would NOT optimize multi-tasking at all,
>but would turn the Amiga into a single-tasking machine a la Switcher.
>ONLY one task could then run at a time, the currently active one.
...
>				-Mitsu

	Sorry, but that is not what he meant.  What he wants (At least I think
so) is a classic scheduling strategy for multitasking systems to give good
response time, while still allowing background tasks to run.  What you do is
up the priority of any task that gets USER input, temporarily.  So when the
user clicks the mouse, or types a letter (or line), his tasks gets a nice
fat slice of time for, lets say, half a second, and then it drops back down
to normal.  This produces greatly improved response time when CPU-bound
tasks are running in the background, without producing a dramatic slowdown
(or stoppage) of the background task.  Even what he actually said (raise
it until you give input to another task), isn't what you took it as, backgound
tasks would still run if the forground task ever Wait()ed, or otherwise
blocked.

	Randell Jesup
	jesup@steinmetz.uucp
	jesup@ge-crd.arpa