🚀 go-pugleaf

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.