Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!harvard!spdcc!halleys!ulowell!page From: page@ulowell.cs.ulowell.edu (Bob Page) Newsgroups: comp.sys.amiga Subject: Re: RESIDENT Message-ID: <1340@ulowell.cs.ulowell.edu> Date: Wed, 3-Jun-87 15:14:16 EDT Article-I.D.: ulowell.1340 Posted: Wed Jun 3 15:14:16 1987 Date-Received: Sun, 7-Jun-87 03:52:46 EDT References: <8706020852.AA18103@cogsci.berkeley.edu> Reply-To: page@ulowell.cs.ulowell.edu (Bob Page) Organization: University of Lowell Lines: 97 This is about 100 lines long, but I really did cut where I could. Back in November I wrote an expose on the dangers of RESIDENT. Here is a portion of what I posted. + Message-ID: <790@ulowell.UUCP> + Date: 27 Nov 86 17:20:22 GMT + + Ahem. The CLI-resident version of CLI doesn't make a copy of the + initialized data segments. Programs share both code AND data. If I + have any initialized data that later gets changed, the next time + it gets run you'll get the last value before exiting. And Even Worse + is that two invokations will use the same variables. Checksumming + would defeat this - the CLI should be smart enough to make a copy + of the data - or each program would have to have special startup + code that copied the data to a safe place. The first solution is + much easier and safer, except for one thing: + + The RESIDENT command essentially does a LoadSeg() allocating + BSS hunk space as well. Then the CLI-resident just USES THAT + SEGMENT LIST directly. This means the whole resident idea is + useless unless you have a program that allocates its own BSS and some + space to copy the data to. Thus, we're back to my second suggestion + of special startup code. + [...] + Now, if you have multiple data hunks, the problem is compounded. + I repeat - stay away from RESIDENT and CLI-RESIDENT. For those netters + who don't have it - you don't want it. I agree the idea is nice - + hey, it's great - but the current way of handling things is broken. bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) recently wrote: >RESIDENT is limited, but NOT broken. It works *wonderfully* for what it was >designed for, BCPL. It is true that it cannot make BSS hunks and it is true >that the code must be REUSABLE and REENTRANT; but these are irrelevant to the >commands that need to be made RESIDENT. I don't think it is a good idea to promote RESIDENT in its current form, since the number of things you can safely use it for is pretty small, and not many people have it anyway (which happens to be a Good Thing). > RESIDENT is the best thing since sliced bread The IDEA is. The command is not. In addition, Lattice's fork(), Manx's exec(), the RUN command, and every CLI/Shell except CLI-RESIDENT have no idea about resident commands. >Novice users especially should use RESIDENT, so they get addicted to >how fast it is. Arrghh! Then they make emacs, more and ls resident, and wonder why the machine keeps blowing up. No thanks. Besides, don't novices use WorkBench? :-) >Perhaps C-A could say something official-like for the rest of the world's >conscience. AndyF said: + From: andy@cbmvax.cbm.UUCP (Andy Finkel) + Message-ID: <1005@cbmvax.cbmvax.cbm.UUCP> + Date: 18 Nov 86 21:29:15 GMT + >>Some more thought is going to have to be put into the concept + >>before it sees the light of day again. [and...] + It was designed for BCPL programs, we put it into the developer + releases, it won't appear again until it works more generally. Seems solid enough advice, even if implied. Of course, he also put at the end: + "Never make anything simple and efficient + when it can be complex and wonderful." But back to Bryce: >BTW: resident was initially released on a disk with no distribution >restrictions printed on it, and it does not contain a copyright notice. Wasn't it released to developers only, under the terms of the non-disclosure agreement? >For reasons other that the one above I have been working on a "RESIDENT". >Beat on me hard enough and I will finish and release it. Yay. Do it. >This really skirts the issue, as the "RESIDENT" command needs >the "cli-resident" file to be meaningful. It needs a CLI/Shell that understands "sticky" text segments. You might want to hack it into Matt's shell ... you'll need a command to make it resident and modify the exec code to look in the resident list, then do something like checksum the segments to make sure nothing's changed while you weren't looking. Or have the exec code allocate data space for each invokation. In other words, I don't think a RESIDENT command in and of itself will do the trick. But you knew that. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}