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!             \/