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,af0c6ea85f3ed92d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.235.4 with SMTP id ui4mr4917235pbc.3.1330995129664; Mon, 05 Mar 2012 16:52:09 -0800 (PST) MIME-Version: 1.0 Path: h9ni43956pbe.0!nntp.google.com!news2.google.com!feed-C.news.volia.net!volia.net!news2.volia.net!feed-A.news.volia.net!news.ecp.fr!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Arbitrary Sandbox Date: Mon, 5 Mar 2012 18:52:05 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1330995128 577 69.95.181.76 (6 Mar 2012 00:52:08 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 6 Mar 2012 00:52:08 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-03-05T18:52:05-06:00 List-Id: "Robert A Duff" wrote in message news:wccr4xpnkh6.fsf@shell01.TheWorld.com... > tmoran@acm.org writes: ... >> BTW, the only real problem we had with bad user programs was one grad >> student who had heard about "virtual memory" and wrote his program to use >> large arrays. Unfortunately he accessed them column-wise, while they >> were >> stored row-wise, so his program swapped horribly. In 1970 it would have >> taken a very smart compiler indeed to prevent that problem. > > That problem still exists. I've seen cases recently, on both windows > and linux, where a rogue program swapped horribly, and put the system > in a state where it won't listen to the keyboard or mouse, so I can't > kill the program. It seems to me it's possible to design an OS that > wouldn't do that. Indeed, until I got rid of them, there used to be a bunch of ACATS tests that *tried* to exhaust memory, and thus often had that effect. I remember that we had to put an artificial memory limit into our early Windows NT compilers to keep those tests from crashing our solitary Windows NT machine (which also doubled as our domain controller, so that was not good.). One of the first things I did when I took over the ACATS was to get approval to remove those tests from the test suite. (I think I actually ended up allocating a large data structure, but bounded the size to 32MB, rather than just running until Storage_Error was raised.) Randy.