Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!topaz!uwvax!husc6!harvard!adelie!axiom!lewis
From: lewis@axiom.UUCP (Lewis Gordon Pringle Jr.)
Newsgroups: net.micro.mac
Subject: Re: Re: Multitasking Considered Useless?
Message-ID: <305@axiom.UUCP>
Date: Fri, 22-Aug-86 13:32:17 EDT
Article-I.D.: axiom.305
Posted: Fri Aug 22 13:32:17 1986
Date-Received: Sat, 23-Aug-86 05:21:19 EDT
Organization: Axiom Technology, Newton MA
Lines: 37



>   > But seriously, the problem is not the Mac os.  It is the hardware.
>   > Apple was right to not try to put multi-tasking on the Mac.  Without
>   > an MMU, multi-tasking is dangerous.
>
>   It would be better stated that without an MMU, sloppy programming in a
>   multitasking environment is dangerous.  With the MMU, if I allocate a 1K
>   chunk of memory and then write to it as a 2K chunk, the hardware protects
>   it from being clobbered, whereas without the MMU I could stomp on memory
>   being used by another process or task.  But its still my error that's
>   causing the problem.  In a properly written program, I won't have the
>   ability to clobber the memory of another task.

No.  You've missed several important points.  Context switch time is much
less if all you have to do is move around page table entries, rather
than whole blocks of global data.  The mac maintians lots of global
information which it is not "buggy" to update. What this means is that
it would take too long to let each application have time to run if
the OS has not MMU support.  Also, there are UserInterface issues that
you are glossing over.

The mac was not designed to do MultiProcessing, and so it was OK for
Apple to leave many issues unresolved.  Like when a backround process
puts up a dialog box, what happens?  SIGTTOU ?  You get two dialog
boxes from different applications at the same time?  Maybe
you have different classes of applications, and only non-interactive
ones can be run in the backround?  Lotsa possabilities!

Its not as simple as just putting in scheduling code, and allowing
new process creation primitives.  Some real thought needs to be done.


-- 
Disclaimer: I'm just trying to assure my place in the AssHoles Hall Of Fame.

UUCP:	lewis@axiom@{linus,harvard,lpi,drilex,adelie}.UUCP