Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <7391@fy.sei.cmu.edu>
Date: 1 Jun 90 13:09:43 GMT
References: <402@newave.UUCP> <3300131@m.cs.uiuc.edu> <5031@quanta.eng.ohio-state.edu> <1990May28.083518.26003@laguna.ccsf.caltech.edu> <54992@microsoft.UUCP>
Reply-To: firth@sei.cmu.edu (Robert Firth)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 24

In article <54992@microsoft.UUCP> edwardj@microsoft.UUCP (Edward JUNG) writes:

>Cooperative multitasking does not guarantee best response time for the
>foreground process.  Actually, it offers the possibility of exceptional
>and uncontrolled degradation of the foreground process.

Right on!  I get to share a Mac with the rest of this floor.  It is a
Mac IIcx, with power, size, and capability that would have been
unbelievable 10 years ago.  It has a print spooler.

Now, a print spooler doesn't take that many cycles.  It's a traditional
background task.  So, when the spooler is running, how come the screen
can go dead for 15 or 20 seconds?  (I know; I timed it yesterday)  Why,
because it has to wait for the spooler to kindly decide to relinquish
control of the CPU.

So, here I am, with approximately 100 times the machine resources of
the PDP-11/45 that I used to share with 8 or 10 other timesharing
users, and the response time can be 100 times worse.  That's a
degradation of four orders of magnitude, all due to one key design
decision.

The ability of hardware engineers to enhance is far outmatched by
the ability of software engineers to degrade.  And you may quote me.