Path: utzoo!utgpu!watmath!att!pacbell!ames!haven!grebyn!ckp From: ckp@grebyn.com (Checkpoint Technologies) Newsgroups: comp.sys.amiga.tech Subject: Resource tracking Message-ID: <12255@grebyn.com> Date: 9 Aug 89 15:20:44 GMT References: <1610@uw-entropy.ms.washington.edu> <195@VAX1.CC.UAKRON.EDU> <26900@agate.BERKELEY.EDU> <4084@sugar.hackercorp.com> <7570@cbmvax.UUCP> Reply-To: ckp@grebyn.UUCP (Checkpoint Technologies) Organization: Grebyn Corp., Vienna, VA, USA Lines: 22 In article <7570@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > > Many requests for what people call "resource tracking" are actually >requests for memory protection. I consider any program on ANY os that doesn't >free what it allocates (memory, file locks, whatever) to be at best poorly >written. > Well let me register myself as one who really wants resource tracking, complete and unabridged. By this I mean more than memory protection, I mean the ability to have a process fault and the system clean up all the resources it held at the time - file locks, semaphores, allocated memory, windows, screens, devices... everything. And then the system continues to run. This is what I mean by resource tracking. To me, memory protection is just a way to decide *when* to fault a program (when it treads on unowned memory), just as would an illegal instruction trap or address error. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/