Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!qantel!lll-lcc!lll-crg!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: net.micro.mac,net.micro.amiga
Subject: Re: BYTE issue of September 86 focuses on the 68000
Message-ID: <1146@hoptoad.uucp>
Date: Sun, 28-Sep-86 22:30:54 EDT
Article-I.D.: hoptoad.1146
Posted: Sun Sep 28 22:30:54 1986
Date-Received: Tue, 30-Sep-86 19:53:02 EDT
References: <3868@ut-ngp.UUCP> <3374@ism780c.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Centram Systems, Berkeley
Lines: 53
Xref: watmath net.micro.mac:8010 net.micro.amiga:4987

Hertzfeld recently admitted that the Mac OS just did not work well for
multitasking.  I wasn't there, but I see a number of reasons.

First, the whole idea of low-memory globals.  A lot has to be switched in
and out with each context switch.  Even on a memory-managed system, the
switch would require a lot of actual variable setting rather than a single
change to a memory map register, because some of the globals needing
switching are in the middle of generally global (non-switched) areas, and
there are global areas in the middle of switched areas.

I have a paper design that removes the global-switching overhead for most
context switches, but it is not pretty, and for some applications (those
that access lots of low-memory globals themselves, rather than leaving them
for the managers) it will degrade to the simplistic algorithm.  Even in this
design, there are still around eighty bytes that have to be switched every
time, which also requires cycles for the code to do the switching as well as
for the switched data.

Second, the system file.  This requires the ugliest part of Switcher context
switching: all resources in the system file which are not marked for the
system heap must be switched in the system file resource map on each context
switch.  There is no way this could be sped up with memory management.
Also, any application may now add resources to the system file, meaning the
file can be corrupted, crashing everyone else.

Third, the system heap.  This is a very bad idea on a multitasking, memory
managed system; and multitasking, non-memory managed systems tend to crash a
lot.  The problem is that existing applications are perfectly capable of
allocating storage in the system heap, meaning they need write access to the
system heap zone; they almost always reference resources in the system heap,
so they need read access as well.  This means any process can see data
belonging to other processes, a security hole; and any process can run amuck
and corrupt the system heap, causing the whole system to crash.

Fourth, the asynchronous parts of the system, particularly the vertical
retrace queue and file/device completion routines.  These just don't work
with memory management, because user processes can't be allowed to run in
the OS kernel memory environment.  Some way has to be found to make them run
in the user process space after scheduling the process to run; but
applications may depend on them running asynchronously as soon as possible.

For these reasons, I think Apple is going to have to do an incompatible
revision of the operating system to support multitasking really well.  It
will have to get rid of the system heap, redefine the role of the system
file, get rid of all switched low-memory globals, and redefine asynchronous
parts of the operating system.  This is not impossible; remember that
converting to HFS required new versions for half or more of the released
applications.  I'm just sorry they didn't have the foresight to deal with
these issues during the design of the operating system.
-- 
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)