blandy@marduk.cs.cornell.edu (Jim Blandy) (06/13/88)
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.
scott@applix.UUCP (Scott Evernden) (06/13/88)
Most of the time I crash not because of random scribblings, but more often due to stack unwinding trouble, divide by zero, bus errors, illegal instructions and that sort of thing. With a little work, most of these really should be recovereable but aren't. How does GOMF do it? Why doesn't the OS provide GOMF-like recoverablilty? -scott
aleks@well.UUCP (Brian J. Witt) (06/26/88)
In article <723@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >Most of the time I crash not because of random scribblings, but more often >due to stack unwinding trouble, divide by zero, bus errors, illegal >instructions and that sort of thing. > Actually, what some memory management might provide is the ability to remove the faulting process completely. Freeing file handles, locks memory, libraries, etc (see ARP people for more resources to track). An article about CAOS, the original planned DOS, Carl S. envisioned packages that processes were encapsulated, and could be "cut out" of memory without affecting anything else! Waht a neat idea :-) >-scott -- I bought it for the multi-tasking, -- but the salesperson sez it does graphics, too! -- brian