Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!purdue!haven!wam!cscwam.umd.edu!nebel
From: nebel@cscwam.umd.edu (Chris D. Nebel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Why do application partitions exist?
Message-ID: <1991Feb11.190258.11268@wam.umd.edu>
Date: 11 Feb 91 19:02:58 GMT
References: <1991Feb6.085236.15677@sol.UVic.CA> <39068@cup.portal.com> <91041.160007CXT105@psuvm.psu.edu>
Sender: usenet@wam.umd.edu (USENET Posting)
Organization: University of Maryland at College Park
Lines: 41

In article <91041.160007CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes:
>*HOWEVER*, now that we've determined that having one heap shared by all
>applications is in fact feasible, the real question is "Why didn't Apple
>do it that way when they wrote MultiFinder."  I suspect it's because the
>application structure makes some pretty heavy demands on things like global
>variables, etc.  Remember that every application has to have its own A5
>world!

Every application has to have its own A5 world now, under the existing scheme.
You have to deal with switching stacks and A5 worlds no matter how you
implement multitasking.  The problem is where are you going to put them,
since in the single-application model, they exist outside the heap.  Really,
though, there's no reason they couldn't be allocated as non-relocatable blocks
in the global heap.

Someone pointed out that there is a problem with putting an application's
stack inside the global heap, since it might trash some other app if it gets
too big. (Under the current scheme, it'll only kill itself.)  You can get
around this by allocating the stack directly above the CODE 0 and CODE 1
resources of the parent app, since they're always there and locked.  So
unless the stack gets very big very fast, it will only stomp on its own
application. (Yes, I know having a real memory manager would make the problem
go away, but lots of people don't have them!)

The only good objection I've heard so far is that some apps decide to suck up
all of availible memory immediately.  Under a global heap system, this is
decidedly anti-social behaviour, and as such would eventually go away. In the
meantime, though, you could have an option in the Get Info box that said
"limit this app to at most -- K of memory."  By default, it would be however
much memory you had, and unless an app was anti-social, you'd never have to
touch it.

C. Tate is right; global heap management is obviously possible.  My question
is -- since everything I've heard so far indicates that global heap MM would
have been just as easy (or hard :) to implement as the partition scheme Apple
actually came up with, and since global-heap-style has a number of distinct
advantages, why did they go with partitions?


Chris Nebel
nebel@wam.umd.edu