Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!bionet!agate!eos!aio!vf.jsc.nasa.gov!kent From: kent@vf.jsc.nasa.gov Newsgroups: comp.sys.amiga.hardware Subject: Re: Amiga Mem management and resource tracking Message-ID: <1991Apr4.082816.1@vf.jsc.nasa.gov> Date: 4 Apr 91 14:28:16 GMT References: <1991Apr2.235710.13984@news.iastate.edu> <1991Apr3.201259.8377@engin.umich.edu> <1991Apr3.153236.1@vf.jsc.nasa.gov> <1991Apr3.230854.17091@jato.jpl.nasa.gov> Sender: news@aio.jsc.nasa.gov (USENET News System) Organization: NASA Johnson Space Flight Center Lines: 32 >>Memory protection would prevent a program crash from crashing the whole >>machine. The memory management unit would limit each program to its own memory >>space. Thus, the program could not go stomping off into memory with muddy >>boots. Hence the end of the Guru. >> > Memory protection would not be the end of the GURU. I speak from > experience. There are other types of errors which can be induced without > memory violations. > That is true it would not end the GURU, it would eliminate a whole class of GURU errors. Programs could not stomp on the OS lists. >>Resource tracking would allow the operating system to deallocate all resources >>a program failed do because it crashed or the programmer did not write code to >>deallocate all memory, devices and so on. >> > Resource tracking is a neat feature, but it would entail greater > memory consumption and eat up more cycles. Not closing files or deallocating > memory, doesn't cause an immediate system failure. Stomping off into memory > with muddy boots does. I think memory protection is more important. > > -jeff > I agree, memory protection is more important than resource tracking. It would take a bit to memory for the OS to keep lists of resources. The cycles would be very low and only at startup or shutdown of a process or task. Mike Kent - Lockheed Engineering and Sciences Company at NASA JSC 2400 NASA RD One, Houston, TX 77058 (713) 483-3791