Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: New Exec calls needed: (was Re: Track buffers)
Message-ID: <8705222220.AA29170@cory.Berkeley.EDU>
Date: Fri, 22-May-87 18:20:41 EDT
Article-I.D.: cory.8705222220.AA29170
Posted: Fri May 22 18:20:41 1987
Date-Received: Sat, 23-May-87 17:24:38 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 24

>Well, I've been thinking again (when will I learn my lesson).  What I 
>was thinking was that it would be great to have a trackdisk.device that
>used up all of available (chip?) ram for track buffers, and released the buffers
>on a least recently used basis when memory was allocated (in sort of the
>same way that libraries stick around until the memory is needed).

	What is needed is another couple of Exec calls allowing one to
install a "memory low" signal to task X (allowing any number of tasks to do
this).  You would specify some sort of low-water mark below which you
want to be notified that memory is running low, and a high-water mark
above which you want to be notified that there is plenty of memory.  The marks
should be placed far enough away so that you don't get into any infinite 
oscillation loops (could occur when several tasks are using the feature).

	Then, Exec would signal the specified tasks (with either the high
water or low water signal) when the specified condition occurs.

	The end result is that the system could dynamically utilize the 
available memory without those tasks (like RAM:) having to poll the amount 
of free memory available every so often.  For instance, This feature could
be used to automatically choose buffer sizes for stdio file pointers and
dynamically change them if the memory load changes.

					-Matt