🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #8473

Re: Process Killing (SQUISH!)

#8473
From: Aaron Avery
Date: Wed, 13 Apr 1988 11:51
20 lines
1559 bytes
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)
Technical Details
Message-ID: <1560@puff.cs.wisc.edu>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!uwvax!puff!avery
References: <8804121334.AA10141@jade.berkeley.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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