Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!zazen!uwvax!titanic.cs.wisc.edu!tonyrich
From: tonyrich@titanic.cs.wisc.edu (Anthony Rich)
Newsgroups: comp.sys.mac.system
Subject: Re: Turning off time slices in S7
Message-ID: <1991Jun1.070626.2853@spool.cs.wisc.edu>
Date: 1 Jun 91 07:06:26 GMT
References: <0E010021.82xzfh@gla-aux.uucp>
Sender: news@spool.cs.wisc.edu (The News)
Organization: U of Wisconsin CS Dept
Lines: 27

Larry Rosenstein writes:

> It is straightforward to write a program that sends a quit Apple event to
> all running apps (including the Finder) and then launches [a time-critical]
> app such as Tetris [...].

OK, but what about killing live background extensions like SuperClock that
aren't "launched apps" in the usual sense?  Maybe they shouldn't be "killed",
just "put on hold" until the time-critical foreground app is finished.
INITs/CDEVs shouldn't be killed, then require manual re-launching later.

Glenn Austin writes:

> Well, considering the foreground application has control over when
> the application is switched out, [switchouts] shouldn't be a problem.

As I understand it, an app has control over *when* it's switched out, but not
for *how long*--so I don't think cooperative multitasking solves the problem.
It's considered "Multifinder friendly" for an app to give up the CPU once
in a while so that other tasks like modem downloads don't timeout.  The hard
part for a time-critical app is getting the CPU *back* quickly enough.

An interesting solution might be to have separate foreground and background
processors.  That way, the foreground app wouldn't need to be interrupted
to handle the background stuff.  If a user interface should give the user
the illusion that the computer is always paying attention, why not dedicate
a processor to maintaining that illusion?