From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!meganewsservers.com!feeder2.on.meganewsservers.com!feed.cgocable.net!read2.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> <52fBd.42256$nV.1324414@news20.bellglobal.com> <33li96F422q0fU1@individual.net> <33qh7eF42pn2fU1@individual.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Sun, 02 Jan 2005 22:13:47 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read2.cgocable.net 1104721960 24.150.168.167 (Sun, 02 Jan 2005 22:12:40 EST) NNTP-Posting-Date: Sun, 02 Jan 2005 22:12:40 EST Organization: Cogeco Cable Xref: g2news1.google.com comp.lang.ada:7396 Date: 2005-01-02T22:13:47-05:00 List-Id: Luke A. Guest wrote: > On Sun, 02 Jan 2005 15:09:36 +0000, Marven Lee wrote: >>Michael van Elst wrote: >>>Jeroen T. Vermeulen wrote: >>>>One major problem is that the Amiga's shared libraries act as >>>>OOP-style objects, matching responsibilities to context much more >>>>elegantly than other OSs do (where process ID is everything). A >>>>process conceptually switches to a different protection domain when it >>>>calls a library function. >>> >>>Correct. That's why a protected AmigaOS must support protection domains >>>not only for processes but also for libraries. That's a generalization >>>of the UNIX model. There you have protection domains for each process >>>plus one protection domain for the kernel which is mainly a huge >>>library. In AmigaOS every library would need its own protection domain >>>and context switches must be as lightweight as possible. > > I certainly wouldn't do it like that. On hardware that has an MMU (most > these days), that would result in a very slow system due to the amount of > context switches, this is why the libraries need to be mapped into the > address space of the running app, i.e. shared between applications. There is no argument about the overhead in this case. However, I maintain that if enough people start using operating systems that are implemented this way, they'll finally enhance the hardware to correct this problem. Until then, people may as well continue to say "we can't do it that way". I believe the problem is fixable in hardware. >>>I've never been too keen on the single address space systems. >> >>I like the way you can pass areas of memory between address spaces >>without having to search for a suitable place to stick it in the >>destination address space, they can use the same region of the address >>space in each address space. This might also be useful when copying >>data through a series of address spaces. I don't think having pointers >>meaning the same thing in different address spaces is a benefit though, >>especially in messages where a pointer could point outside a message >>without any error checking. > > Single address space OSes are only useful if you have loads of memory and > you're not using that many apps at any one time. So you need to be more > careful with the sizes of apps. You will run out of memory, especially > considering the size of apps these days. > > Luke. Even when you have address space to "burn", you can quickly use it up if you decide to map files into memory. Security is another potential issue (you would have to map out pages that you don't want others to see etc.) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg