Xref: utzoo comp.sys.mac:14147 comp.windows.misc:327
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!polya!ali
From: ali@polya.STANFORD.EDU (Ali Ozer)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: Shy pre-emption++
Message-ID: <2158@polya.STANFORD.EDU>
Date: 18 Mar 88 15:00:07 GMT
References: <7670@apple.Apple.Com> <6970@drutx.ATT.COM> <2154@polya.STANFORD.EDU> <7731@apple.Apple.Com>
Reply-To: ali@polya.UUCP (Ali Ozer)
Organization: Stanford University
Lines: 24

In article <7731@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes:
>I think you have a point, but for a different reason.  The only
>time you want the WP to have highest priority is when you  are interacting
>with it.  At all other times you want it to have the lowest priority.
>MultiFinder accomplishes this by guaranteeing highest priority to the
>application with the frontmost layer, at the expense of all other
>layers.  However, when the WP is not frontmost, it gets no time at all
>and will never interrupt the ray tracer from its task.
>
>One more point about prioritization is that it had better be dynamic
>(e.g. frontmost task vs. the rest in MF).  Otherwise, priorities assigned
>in a vacuum will not work well with different task mixes.

True. This of course is automatically obtained if tasks normally call 
a sleep() or wait() routine (WaitNextEvent()as opposed to polling-type
GetNextEvent() under MF, correct?). On the Amiga all programs use the
Wait() routine to wait for events (input/output/timer/disk/etc...)
so you automatically have "dynamic" prioritization. Thus an high-priority
WP will be fully asleep and consuming no CPU while not being used. But
it'll be ready to wake up and jump at any instant, because of its high
priority. (Of course, lack of virtual memory helps. 8-) No UNIX-like disk
grinding when you switch back to your editor after an hour of non-use...)

Ali Ozer, ali@polya.stanford.edu