Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!daemon
From: miller@CS.ROCHESTER.EDU (Brad Miller)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Protected mamory (SIC)
Message-ID: <1989May18.194017.15801@cs.rochester.edu>
Date: 18 May 89 23:40:16 GMT
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 48

In article <8288@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes:
>In article <1989May11.193812.2552@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes:
>>
>>Protection issues needed to support multiple users aren't an issue with
>>single users.
>
>That's hard to swallow.  So it isn't an issue that a bug in my word processor
>can crash my machine?  Taking my spreadsheet, drawing program, and everything
>else with it?  I would personally (almost!) trade all the new features in
>System 7.0 for memory protection.

[Sorry for the late reply]

If a bug in a word processing program crashes your machine, protected memory
won't necessarily help your other applications. What I think you mean to say
is that memory protection can intercept a certain class of bugs and prevent
a possible machine crash, or other memory corruption.

The problem is that while this is perfectly true, this protection disallows
a class of IPC that may well be to the user's benefit. Consider the sorts of
issues that occur when an incremental compiler wants to replace the
definition of a function currently being used by another process. This
redefinition may well be intentional; it is exactly what the user wants to
do. The point is that presumably in a single-user multi-process situation,
all the processes are working FOR that user, and should be allowed to freely
intercommunicate. A single large address space enhances this communication,
if memory protection doesn't prevent access. Incremental compilation you may
consider to be esoteric, but the same issues come up in debuggers, parallel
programming, coroutining (consider the routines accessing a single array),
and a variety of other situations.

That doesn't mean that a particular application shouldn't be able to protect
itself from outside access, or even protect others from itself; given you
know the machine has an MMU you can do just that. I just don't think it's
something the OS should provide by fiat, because it would prevent writing a
large interesting class of applications. (And besides, it would slow the
machine down. :-)

If you DO want some sort of OS level protection, then it should be done at
the OBJECT/TYPE level (e.g. tags) rather than at the memory address level.
That would allow, say, multiple threads to properly use/invoke functions,
etc. but not e.g. randomly write. (It also allows shared libraries to be
implemented and protected against misuse). 

Bottom line: I don't think simple memory protection is worth the cost in a
single user machine; good type & use checking is expensive and isn't likely
to occur in 7.0; and you really need hardware support which the MAC line
doesn't have. (68050 anyone?)