backstro@silver.bacs.indiana.edu (03/28/88)
/* Written 3:04 pm Mar 21, 1988 by lel@wuphys in silver:comp.sys.amiga.tech */ /* ---------- "Process Killing (SQUISH!)" ---------- */ Many moons ago, there was a discussion on the net about killing errant processes. Obviously, since the Amiga doesn't implement resource tracking, killing a process would be difficult. Now, I am NOT a guru, so I'm sure I must be missing something here. Why not write a program that lists all processes and their priorities. Then allow the user to select a given process via mouse and have that process "killed". This could be done by changing the process's priotity to, say, -256. Then, start another process with priority -255 that just EATS CPU time (a simple loop or something pretty). You could do this directly by fiddling with exec's lists but I'd hate to fiddle with these. Next, close all windows and screens the process (by clicking on them if necessary, ala GOMF 1.0). In general, clean up everything you can find. Question, would it be safe to just remove the process from the queue rather than setting it's priority to -256 and setting up another process at -255? I'd sit down and write this thing if I had time. It could be VERY useful. Especially since I have plenty of fast ram but only .5 meg chip. The screen of an errant program can gobble a lot of this. Why hasn't this been done? It would be easier than GOMF... Any gurus out there have any better ideas? ========== IBM is a Division of Sirius Cybernetics Corporation "their fundamental design flaws are completely hidden by their superficial design flaws." - "So Long And Thanks For All The Fish" Lyle Levine: Paths -> ihnp4!wuphys!lel uunet!wucs!wuphys!lel /* End of text from silver:comp.sys.amiga.tech */
avery@puff.cs.wisc.edu (Aaron Avery) (04/13/88)
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)