Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!lll-crg!seismo!husc6!panda!genrad!decvax!wanginst!ulowell!page
From: page@ulowell.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: 1.2 resident query
Message-ID: <790@ulowell.UUCP>
Date: Thu, 27-Nov-86 12:20:22 EST
Article-I.D.: ulowell.790
Posted: Thu Nov 27 12:20:22 1986
Date-Received: Fri, 28-Nov-86 07:08:56 EST
References: <1017@husc2.UUCP> <1607@amiga.amiga.UUCP> <760@ulowell.UUCP> <1005@cbmvax.cbmvax.cbm.UUCP>
Reply-To: page@ulowell.UUCP (Bob Page)
Organization: University of Lowell
Lines: 51

andy@skipper.UUCP (andy finkel) wrote in article <1005@cbmvax.cbmvax.cbm.UUCP>:
>In article <760@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes:
>>It didn't even work correctly for BCPL programs!  Sure, it worked
>>somewhat, but the Resident command allocated more space than it
>>should have - including a data segment that should be allocated on
>>startup, not when the program was installed as resident.
>
>Are you positive about this ? It seems like if it was done that
>way we'd have to have a resident and non-resident version of each
>BCPL program.

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.

>>Even a _little_ more thought would have been nice ... like checksumming
>>the segments to see if they had changed - if so, allocate space for
>>new ones - in other words, take what you can and replace the dirty
>>segments from the disk.  I'm not flaming you guys, I'm flaming MCC.
>>
>BTW, checksumming segments sounds like a poor idea...it defeats the
>purpose of the shareable requirement...that 2 or more processes can share
>the same copy of a program.  Were you envisioning global variables ? 

Yes - but checksumming doesn't defeat anything but unreliable data.
You can't share a copy of a program when one or more segments are no
longer pure - and it doesn't take long to checksum the segment, so
why not do it?  I don't see why it is a bad idea.

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.

..Bob
-- 
Bob Page,  U of Lowell CS Dept.      ulowell!page,  page@ulowell.CSNET