Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!corton!inria!seti!adele.inria.fr!pete
From: pete@adele.inria.fr (Pete Keleher)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to malloc memory VERY dynamically and not out of app heap?
Message-ID: <2029@seti.inria.fr>
Date: 27 Mar 91 08:17:00 GMT
References: <669949449.1@mmug.fidonet.org.org>
Sender: news@seti.inria.fr
Organization: INRIA, Le Chesnay - France
Lines: 37

In article <669949449.1@mmug.fidonet.org.org>, Jim.Spencer@p510.f22.n282.z1.fidonet.org.org (Jim Spencer) writes:
|> 
|> John T. Nelson writes in a message to All
|> 
|> JTN> Now... in order to handle those BIG files this means that I need 
|> JTN> an app size that's extremely large (several megabytes) but that 
|> JTN> means I cripple the application because then it won't run on 
|> JTN> smaller Macs with perhaps only two meg of memory. If I set the 
|> JTN> app size too small then it doesn't run on those big files. It 
|> JTN> would be nice to newPtr my space from a "free" area whose upper 
|> JTN> limit was not fixed and tied to the application's expectations. 
|> JTN> 
|> JTN> What does one do in these sort of situations or have I missed 
|> JTN> something conceptually? I would like to be able to run an app 
|> JTN> without telling the OS how much memory I need because I don't 
|> JTN> know how much.
|> 
|> What you are missing is that if you really plan to handle really big
|> files, on the order of several megabytes, you need to come up with a
|> way to only read part of the file into memory at a time.  Even those
|> with lots of RAM won't go for a text processer which needs really
|> huge amounts of memory just so the entire file can be in RAM at the
|> same time.

I disagree. You are saying that each application should manage its own
virtual memory. It is precisely to avoid this that we have
application-independant virtual memory supported by the system. If you want
to read a 10meg file, read into memory and let the system page it on and
off of disk.

I agree totally with earlier comments to the effect that the the ability to
dynamically change your address space size is a major lack of 7.0.
-- 
						Pete Keleher

INRIA, B.P. 105, 78153 Rocquencourt Cedex, France.  Tel.: +33 (1) 39-63-52-93;
fax: +33 (1) 39-63-53-30; e-mail: pete@sor.inria.fr