Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!steinmetz!jesup
From: jesup@steinmetz.steinmetz.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: Does RAM: ever retry?
Message-ID: <7133@steinmetz.steinmetz.UUCP>
Date: Fri, 28-Aug-87 01:58:24 EDT
Article-I.D.: steinmet.7133
Posted: Fri Aug 28 01:58:24 1987
Date-Received: Sat, 29-Aug-87 14:18:19 EDT
References: <510@sugar.UUCP> <6619@eddie.MIT.EDU> <535@sugar.UUCP> <7069@steinmetz.steinmetz.UUCP> <566@sugar.UUCP>
Reply-To: jesup@kbsvax.steinmetz.UUCP (Randell Jesup)
Organization: General Electric CRD, Schenectady, NY
Lines: 22
Keywords: RAM: out of memory RETRY CANCEL AllocMem

In article <566@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>> The 1.2 Ramdisk has a 'ripcord' of 30K of ram.  If it finds it can't get
>> enough memory, it releases it's 'ripcord' and puts up the disk full
>> requestor.   It won't agree to be un-full until it can get a ripcord
>> back.  This was to solve problems of copying too much to the ram disk
>> and having the system crash.  Without the 30K, it's hard to let the user
>> know the ramdisk is full and let the user correct the problem.
>
>But does that 30K have to be contiguous? And what's wrong with just saving
>enough for the requestor? Surely a system requestor can fit in less than 30K.
>-- 
>-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter

I'm afraid that it does have to be continous, though I don't believe that
it has to be chip ram.  It does have to save more than enough for a requestor,
because if you are to reduce memory usage, it has to be able to load things
such as delete, etc, and you may have to re-arrange windows (or open them)
to fix the problem.

	Randell Jesup
	jesup@steinmetz.UUCP
	jesup@ge-crd.arpa