Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: Editing Files larger than available memory Message-ID: Date: 9 Oct 90 17:23:03 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <6694@sugar.hackercorp.com> <6708@sugar.hackercorp.com> <6754@sugar.hackercorp.com> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 23 In-Reply-To: peter@sugar.hackercorp.com's message of 9 Oct 90 00:46:26 GMT In article <6754@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: OK, you implement it however you want. I'll fix it when you release the source. Limiting the memory usage is even useful for pre-VM UNIX systems (like the ones we have 400 users on at Ferranti). That's the best option. Doing a second memory manager may be more work than is worth it to you; that was my decision. In any case, be sure to send the fixed back so I can consider incorporating them. I may not, but I definitely won't if I don't see them. I will conceede that I haven't decided how to paging files to disk will be triggered yet. I may well wind up with something that allows memory use to be set at start-up time. However, that's _not_ a priority. As I said, the reason for adding that kind of paging is to allow editing of files larger than memory. Extra overhead to constrain the editor isn't on the list.