Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!uunet!mcsun!unido!mpirbn!p554mve
From: p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Memory Protection!
Message-ID: <1137@mpirbn.mpifr-bonn.mpg.de>
Date: 24 Aug 90 17:41:29 GMT
References: <1145.26bd4989@waikato.ac.nz> <1410051@hpcvca.CV.HP.COM>
Reply-To: p554mve@mpirbn.UUCP (Michael van Elst)
Organization: Max-Planck-Institut fuer Radioastronomie, Bonn
Lines: 20

In article <1410051@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes:
>Be careful what you call rediculous.  You are telling me that I should
>put in extra code making the program take longer to write, take more
>space on disk and in RAM, take longer to run, and for what?  You have
>mentioned no advantages.  The only argument you offer in favor of your
>approach ("It is never a bad idea"..) seems to be strictly religious.

That's the same argument that forbids sanity checks on input and we
know how much you can win by just adding some lines of code.

Nevertheless, if resource tracking is done, then it has to be done
somewhere in memory. If you don't allocate the space for resource tables
then the system has to do so, and it might use even more since it has to
deal with all potential resources your task may allocate.

-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."