Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!vax5.cit.cornell.edu!umh
From: umh@vax5.cit.cornell.edu
Newsgroups: comp.sys.mac.system
Subject: Re: Turning off time slices in S7READ/NEXT
Message-ID: <1991Jun3.015035.5222@vax5.cit.cornell.edu>
Date: 3 Jun 91 01:50:35 EDT
References: <0E010021.82xzfh@gla-aux.uucp> <1991Jun1.070626.2853@spool.cs.wisc.edu>
Distribution: comp
Organization: CIT, Cornell University
Lines: 48

In article <1991Jun1.070626.2853@spool.cs.wisc.edu>,
tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: 
> 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?

And this brings us into the brave new world of multithreaded programs and real
operating systems. Since, as we all know, Apple is devoting substantial company
resources to their new, non-Mac machine to be released at the end of '92 (yeah
sure, we all think Apple will stick to a schedule :-) ), it would seem to me
far more sensible to devote effort to creating a decent OS from scratch than
patching an existing mess. Thus my conclusion is that we are never going to see
this on Macs.

Anyone know what the new OS will be? My choice would be to use a Mach kernel to
stop wasting time and get a real OS right away, then add object oriented
extensions from PenPoint to that, plus a final Mac compatibility box+ Toolbox
ala AIX on that. I guess we Mac users will become like Apple II users- never
abandoned by Apple, and with our own weak programs that perform as well as the
hardware will allow, but destined for extinction in 10 years.

Maynard Handley