Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!ames!mailrus!rutgers!rochester!cornell!blandy
From: blandy@marduk.cs.cornell.edu (Jim Blandy)
Newsgroups: comp.sys.amiga.tech
Subject: Protected Address Spaces (Was: Re: Suggestion for 1.4)
Summary: Memory management can be versatile...
Message-ID: <18240@cornell.UUCP>
Date: 12 Jun 88 20:25:20 GMT
References: <8806021714.AA12190@jade.berkeley.edu> <611@myrias.UUCP> <18191@cornell.UUCP> <858@netxcom.UUCP>
Sender: nobody@cornell.UUCP
Reply-To: blandy@marduk (Jim Blandy)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 32

In article <858@netxcom.UUCP> ewiles@netxcom.UUCP (Edwin Wiles) writes:
>>>> [ ... Discussion on workability of protected address spaces ... ]

I received a letter from Rick Spanbauer at SUNY/Stony Brook in which
he pointed out that "protected address spaces" can mean much more than
just making certain addresses off-limits.  He says:

>We need not restrict ourselves to just public rw.  You could have
>public read, public write, public shared, public shared with copy on
>write, etc.

With a little discipline, we could add memory classes other than the
current MEMF_PUBLIC, and work things out.  System stuff could be
protected without much fuss.

However, if the current trend towards very intertwined processes
(which print each other's bitmaps and modify each other's data - VERY
POWERFUL concepts) continues, I would be surprised if people will be
able to tell at allocation time which data will need to be shared and
which won't.  Yes, you can change the status of already allocated
memory, but for fragmented data structures, this could become a royal
pain.

If having other tasks do work for you on your data becomes common
practice, suddenly adding protected address spaces would either
restrict us, or force us to make all our data public rw, a waste.

Rick?  What do you say to that?
--
Jim Blandy - blandy@crnlcs.bitnet
"insects were insects when man was just a burbling whatsit."  - archie
My opinions are my own, not Cornell's.