mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (07/22/87)
People have been pushing the idea of splitting programs into two parts, one that swallows configuration commands or whatnot, and a second that sits in the background and plays server. The server might/might not open or WindowToFront() a window when it gets nudged. This is all good stuff. I went through it with mg a couple of months ago (an Emacs that appears to start in < .5 seconds is a killer demo as far as I'm concerned :-). However, I carried it one step farther. Like Perry with FACC, I wanted mg to free up memory if the sytem needed it. Unlike FACC, I didn't have any problems with mg exiting if it wasn't being used. The only mechanism that seemd to want to work was a library. So I designed (but never built) the following "edit" library: Open - does the usual things, and will start an editor if there isn't one running. Edit - pass the edit server a file name. Wait for the editor to indicate that the user is through with it, and then return. <???> - hooks to allow Edit on multiple files. Close - just decrement the use count. Expunge - exit. Obviously, the Edit and <???> entries can be whatever your application needs. The other three are required for libraries. By doing this, you get the benifit of the user-command/server split, plus a program that will exit if you need the memory and wouldn't otherwise have it running. I never got around to implementing the library part. I'd sure like to see it done, though. <mike -- But I'll survive, no you won't catch me, Mike Meyer I'll resist the urge that is tempting me, ucbvax!mwm I'll avert my eyes, keep you off my knee, mwm@berkeley.edu But it feels so good when you talk to me. mwm@ucbjade.BITNET
perry@atux01.UUCP (Perry S. Kivolowitz) (07/23/87)
In article <4430@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes:
! People have been pushing the idea of splitting programs into two
! parts, one that swallows configuration commands or whatnot, and a
! second that sits in the background and plays server. The server
! might/might not open or WindowToFront() a window when it gets nudged.
!
! This is all good stuff. I went through it with mg a couple of months
! ago (an Emacs that appears to start in < .5 seconds is a killer demo as
! far as I'm concerned :-). However, I carried it one step farther.
!
! Like Perry with FACC, I wanted mg to free up memory if the sytem
! needed it. Unlike FACC, I didn't have any problems with mg exiting if
! it wasn't being used. The only mechanism that seemd to want to work
! was a library. So I designed (but never built) the following "edit"
! library:
!
! Open - does the usual things, and will start an editor if there
! isn't one running.
! Edit - pass the edit server a file name. Wait for the editor
! to indicate that the user is through with it, and
! then return.
! <???> - hooks to allow Edit on multiple files.
! Close - just decrement the use count.
! Expunge - exit.
!
! Obviously, the Edit and <???> entries can be whatever your application
! needs. The other three are required for libraries. By doing this, you
! get the benifit of the user-command/server split, plus a program that
! will exit if you need the memory and wouldn't otherwise have it
! running.
!
! <mike
Mike,
With the Low Memory Server which I posted a while ago the point
is you NO LONGER have to write your own library to get in tune with library
expunge commands. You simply have to write an ordinary user program which
communicates with other programs via a message port.
Register with the LMS and...Poof. Instant Library Sort Of Thing.
Perry
And yes, I'd love to see it too.mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (07/24/87)
In article <498@atux01.UUCP> perry@atux01.UUCP (Perry S. Kivolowitz) writes:
< With the Low Memory Server which I posted a while ago the point
<is you NO LONGER have to write your own library to get in tune with library
<expunge commands. You simply have to write an ordinary user program which
<communicates with other programs via a message port.
I didn't take a very close look at the LMS code, so I may be
completely mistaken. Since I'm not chasing such things now, I'll be
lazy and ask you to enlighten me (and the rest of the net)
electonically, instead of digging out a copy and looking through it.
[You are now warned that I could be completely out of touch with
reality.]
The impression I got was that LMS allowed the user to set various
conditions for "low memory." When those conditions were met, clients
would get told about it, and could do what they wished with that
information.
This is obviously very usefull for a system that keeps a cache in
memory, and ASDG has done the Amiga community another service by
releasing the LMS.
However, mg has a different paradigm for memory useage: it asks for
more when it needs it, and complains when it can't get it (Did anyone
see an antecedent falling there :-). It *never* frees memory after
it's got it - with a few minor exceptions. For mg, and probably
others, it's an all-or-nothing question. Either you hang on to the
memory you've got, or you exit.
Also, mg can't release any resources if some client has the library
open. So the server notification will be ignored under those
conditions.
First a question: do I correctly understand the way LMS works? Or does
it catch all requests for memory, and not pass it on until it can be
satisfied in some way? I'd be very interested in hearing about the
latter if you did it, because it looks like that territory should be
clearly marked "Here be Monsters."
And now a conclusion: The library pardigm fits mg better than LMS
does. Partly because of mg's memory (mis)management strategy, and
partly because of the "if we're open, we can't expunge" that libraries
give you for free.
Like so many other things, this appears to be a case of two slightly
different tools that can both handle many of the same jobs. Having
them both is a good thing, as it allows you to choose whichever suits
the job at hand better.
Thanx,
<mike
--
Here's a song about absolutely nothing. Mike Meyer
It's not about me, not about anyone else, ucbvax!mwm
Not about love, not about being young. mwm@berkeley.edu
Not about anything else, either. mwm@ucbjade.BITNET