Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: SetFunction and expunging libraries Message-ID: Date: 11 Feb 90 05:07:20 GMT References: <551@mpirbn.UUCP> Distribution: comp Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 69 In-Reply-To: p554mve@mpirbn.UUCP's message of 10 Feb 90 16:14:17 GMT In article deven@rpi.edu (Deven T. Corzine) writes: Deven> Just curious... what exactly happens when you SetFunction a Deven> library call and the library is later expunged? Is it possible Deven> to be notified to remove the patch? (or would you have to Deven> patch the Expunge() call of the library to do so?) Or must you Deven> make sure you keep the library open for the duration of the Deven> SetFunction? On 10 Feb 90 16:14:17 GMT, p554mve@mpirbn.UUCP (Michael van Elst) said: Elst> Exactly what you think. If you patch a library you MUST hold it Elst> in memory as long as your patch should work. In a library this Elst> is easily done with opening the library. A device (that's a Elst> special library) may refuse to open from more programs at the Elst> same time, there you have to patch the Expunge vector too. That's what I figured. While I'm thinking along strange lines, what happens if you OpenLibrary() a device or OpenDevice() a library? Apart from being kept in separate lists (you could move one) what neat and interesting things would happen? Or just fireworks? Elst> Carolyn Sheppners program CMD (source on some fishdisk) shows Elst> this method. It patches the devices Expunge and BeginIO vectors Elst> to catch all CMD_WRITES to the parallel or serial device. It Elst> even checks if another patch program has done a second Elst> SetFunction on these vectors because this program might call Elst> CMD's patches in a daisy chain. I'm not sure I see what you mean about this "secondary patch" bit. It checks for a patch when it installs its own? at some other time? both? On a more serious note, can you legitimately have a library which refuses to expunge itself? That is, return some value from the Expunge routine meaning "No." Now, this may sound useless, but I do have a use in mind; I want a library that will be open, but which can find out if the system is in need of memory, so it can free buffers, caches, and the like. Another alternative is a library which is loaded simply for the purpose of being expunged, and when it is expunged, it would signal this task which wants to know about shortness of memory, and it could free memory, while the library is expunged. Then the task can recreate the library to be able to repeat the process. This would work, albeit clumsily, but it is an awful kludge. I guess another alternative would be to patch or more likely replace the AllocMem function, (does AllocEntry call AllocMem, or would I need to patch both?) which would allow more flexible resource management in a cleaner manner. Unfortunately, it would necessitate mucking with the system lists, and taking up the job of AllocMem... *sigh* And, of course, there should be a ReallocMem... Is there a better resource management system for low-memory conditions? Particularly for conditions where there is very little "free" memory in the system, but maybe quite a lot used for, say, disk cacheing... I want to be able to free cache space to satisfy the memory request, but I'm not sure if I can do it synchronously unless I replace AllocMem... Any ideas? Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.