Article View: comp.sys.amiga.tech
Article #8473Re: Process Killing (SQUISH!)
From: Aaron Avery
Date: Wed, 13 Apr 1988 11:51
Date: Wed, 13 Apr 1988 11:51
20 lines
1559 bytes
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!averyReferences:
<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