Path: utzoo!mnetor!uunet!husc6!uwvax!puff!avery
From: avery@puff.cs.wisc.edu (Aaron Avery)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Process Killing (SQUISH!)
Message-ID: <1560@puff.cs.wisc.edu>
Date: 13 Apr 88 11:51:01 GMT
References: <8804121334.AA10141@jade.berkeley.edu>
Reply-To: avery@puff.cs.wisc.edu (Aaron Avery)
Organization: U of Wisconsin CS Dept
Lines: 20

In article <8804121334.AA10141@jade.berkeley.edu> SLMYQ@USU.BITNET writes:
>In a task control structure there's a tc_MemEntry, and it's a list of
>MemLists, which contain MemEntrys (am I right?).  Anyway, the system always
>deallocates this memory when the task is removed.  Your private stack is
>usually put in this list.  If programs would put their allocated memory here,
>then process killing would really be no problem in terms of freeing memory.
>Maybe a set of routines, TAllocMem() and TFreeMem() would help.
Yes, you're right.

I had wondered why the system didn't do just that to keep track of a task's
allocated memory until someone set me straight. The problem with this is, like
you said above, 'in terms of freeing memory'. The problem comes when someone
else uses that freed memory and, say, puts (relative) garbage in a message
port that's going to be replied to at any moment? The problem really is that
partial solutions to resource tracking cause more problems than they solve
(usually), so in this case it's all or nothing.

-- 
Aaron Avery (avery@puff.cs.wisc.edu)
	    ({seismo,caip,allegra,harvard,rutgers,ihnp4}!uwvax!puff!avery)