FATQW@USU.BITNET (02/05/88)
Another one! How about creating some way for user programs to link into the
system, so when an AllocMem() is about to fail, it calls your program, and
your program might just be able to free up the needed memory. This is the
same as the Library/Device principle. For things that are "useful" but not
"essential", or can be re-loaded, make it possible to have the system
automatically free the needed memory.
To do this, just create an Exec List, containing, say, Interrupt structures
or something like that, so when AllocMem is about to fail because of no
memory, it calls the first one and tries again, and then the second, etc.
User programs can simply link into this list, and have their own routines
to free up unnecessary memory.
Bryan
Bryan Ford ////
Snail: 1790 East 1400 North ////
Logan, UT 84321 \\\XX///
Email: FATQW@USU.BITNET \XXXX/eric@hector.UUCP (Eric Lavitsky) (02/06/88)
In article <8802050812.AA17320@jade.berkeley.edu> FATQW@USU.BITNET.UUCP writes: >Another one! How about creating some way for user programs to link into the >system, so when an AllocMem() is about to fail, it calls your program, and >your program might just be able to free up the needed memory. This is the >same as the Library/Device principle. For things that are "useful" but not >"essential", or can be re-loaded, make it possible to have the system >automatically free the needed memory. The hooks were already there - Perry wrote a library that let's your application do exactly what you describe - it's called the ASDG low-memory server, available on Fish Disk #85, or as a bonus when your purchase FaccII - and FaccII takes advantage of the library of course :-) > Bryan Ford //// Eric ARPA: eric@topaz.rutgers.edu "Lithium is no longer available UUCP: ...{wherever!}ulysses!eric on credit..." ...{wherever!}rutgers!topaz!eric - from Buckaroo Banzai SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854