deven@rpi.edu (Deven T. Corzine) (02/08/90)
Just curious... what exactly happens when you SetFunction a library call and the library is later expunged? Is it possible to be notified to remove the patch? (or would you have to patch the Expunge() call of the library to do so?) Or must you make sure you keep the library open for the duration of the SetFunction? 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.
p554mve@mpirbn.UUCP (Michael van Elst) (02/11/90)
In article <DEVEN.90Feb8035053@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: >Just curious... what exactly happens when you SetFunction a library >call and the library is later expunged? Is it possible to be notified >to remove the patch? (or would you have to patch the Expunge() call >of the library to do so?) Or must you make sure you keep the library >open for the duration of the SetFunction? Exactly what you think. If you patch a library you MUST hold it in memory as long as your patch should work. In a library this is easily done with opening the library. A device (that's a special library) may refuse to open from more programs at the same time, there you have to patch the Expunge vector too. Carolyn Sheppners program CMD (source on some fishdisk) shows this method. It patches the devices Expunge and BeginIO vectors to catch all CMD_WRITES to the parallel or serial device. It even checks if another patch program has done a second SetFunction on these vectors because this program might call CMD's patches in a daisy chain. Michael van Elst uunet!unido!mpirbn!p554mve
deven@rpi.edu (Deven T. Corzine) (02/11/90)
In article <DEVEN.90Feb8035053@netserv2.rpi.edu> 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.new@udel.edu (Darren New) (02/13/90)
In article <DEVEN.90Feb11000753@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: >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. Yes. The Expunge() routine just returns zero and Exec does not free anything. (From memory, with salt). This is needed because a library may get Expunge()d while still open! Your Expunge routine must check that the open count is zero before freeing anything. As far as the low memory stuff goes, it's been done. Check out the ASDG LowMem server, which is exactly as you describe. You set up a port and open the library. When memory gets low, the library sends you a message. A copy is available somewhere in the FAM program (probably the binaries) which should be coming to a comp.binaries.amiga posting near you. (It's already been sent and is just waiting for distribution.) Please don't come out with yet another low-memory thing. Keep to the one freely-distributable server and all will be happy. I can email you the thing (docs and all) is you need it in a hurry. -- Darren
p554mve@mpirbn.UUCP (Michael van Elst) (02/13/90)
In article <DEVEN.90Feb11000753@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: >Elst> ... [Carolyn Scheppners CMD program] >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? It checks when terminating, since another program could have SetFunctioned after CMD (and might call the old vectors, i.e. those of CMD) you'd get into troubles if the code of CMD is unloaded. > ... 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. Sounds familiar, there is a lomem.library from ASDG, I think it has been on some fishdisk. This DOES exactly what you want. Michael van Elst uunet!unido!mpirbn!p554mve
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (02/14/90)
In article <10869@nigel.udel.EDU> new@udel.edu (Darren New) writes: >As far as the low memory stuff goes, it's been done. Check out the ASDG >LowMem server, which is exactly as you describe. The ASDG lowmem library has some nasty interaction with the system that causes nasty, unpredictable crashes. Even Perry Kivolowitz (the author) recommends not using it. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University