Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!oracle!news
From: csimmons@jewel.oracle.com (Charles Simmons)
Newsgroups: comp.arch
Subject: Re: Personal OS
Message-ID: <1990Jun2.130207.14198@oracle.com>
Date: 2 Jun 90 13:02:07 GMT
References: <36861@think.Think.COM> <402@newave.UUCP> <3300131@m.cs.uiuc.edu> <9437@pt.cs.cmu.edu> <36849@think.Think.COM> <643@sibyl.eleceng.ua.OZ>
Sender: news@oracle.com
Reply-To: csimmons@oracle.com
Organization: Oracle Corp
Lines: 50

In article <36861@think.Think.COM>, barmar@think.com (Barry Margolin) writes:
> From: barmar@think.com (Barry Margolin)
> Subject: Re: Personal OS
> Date: 29 May 90 01:38:16 GMT
> 
> In article <643@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes:
> >There are many "proofs of existance" to show that a single shared
> >address space for OS and processes can work. That is not to say that
> >it is a desirable environment. Many people (myself included) use a
> >multiuser operating system predominantly with only one active user. I
> >cannot count the number of times I have had a process die with a
> >SIGSEGV. Count each of those as a probable system crash. No thanks!
> 
> OK, maybe I should qualify my point and say that a single address space is
> reasonable when there's a decent language/runtime system.  Almost all the
> system failures we get on Symbolics Lisp Machine are due to hardware
> problems.  The hardware, Lisp language and runtime system make it difficult
> to scribble randomly on memory.  Sure, if a program were to manipulate the
> scheduler's data structures directly and make a mistake it could bring the
> system to its knees, but it's inlikely to happen to a program that isn't
> *trying* to manipulate the OS, and patching the OS is likely to crash any
> system.  When ordinary application programs do get errors (and Lisp
> Machines do lots more error checking, such as number and types of
> arguments, than most other systems) they just invoke the debugger, abort,
> or invoke programmed condition handlers.
> 
> So, I would say that the problem with the Mac is not that it has a single
> address space, but that its typical language and runtime systems don't
> provide adequate for this mode.  Address space protection on multiuser
> systems exists for security; programmers are still responsible for writing
> programs that follow the rules, e.g. only address memory you have
> allocated, pass appropriate arguments when calling library routines or
> system calls, etc.
> 
> --
> Barry Margolin, Thinking Machines Corp.
> 
> barmar@think.com
> {uunet,harvard}!think!barmar

We can, of course, argue this from the other point of view.  The
problem with non-single address space systems is not their lack of a
single address space, but the lack of tools which allow the
information in multiple protected address spaces to be easily accessed
from any of the protected address spaces.  We might envision, for example,
an object-oriented language where a sufficient number of primitives are
implemented on each object to allow each object to efficiently and safely
share the abilities of other objects.

-- Chuck