Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!decwrl!hplabs!hp-sdd!ucsdhub!sdcsvax!beowulf!djohnson
From: djohnson@beowulf.ucsd.edu (Darin Johnson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Suggestions for a kill command
Message-ID: <7238@sdcsvax.UCSD.Edu>
Date: 14 Oct 89 22:05:37 GMT
References: <1661@nigel.udel.EDU> <15530@netnews.upenn.edu>
Reply-To: djohnson@beowulf.UCSD.EDU (Darin Johnson)
Organization: EE/CS Dept. U.C. San Diego
Lines: 28

In article <15530@netnews.upenn.edu> ranjit@grad2.cis.upenn.edu.UUCP (Ranjit Bhatnagar) writes:
>Since it is pretty much settled that it would be impractical
>to add a true 'kill' to the Amiga OS, because of the difficulty
>of tracking and freeing resources, how about a 'suspend' which
>simply prevents a process from using any cpu time.  Much of
>the time, what I want a 'kill' for is to get rid of a program which
>is stuck in a loop and chewing up CPU time.  There should also
>be a 'resume' method to bring the process back to life.  

XOPER will do this, although I haven't tried it.  The NUKE command
in GOMF will also kill a process (but not just suspend it) and try
to return the resources.

What I find annoying, is that if a process has allocated some resource
you need (serial or sound port) and doesn't return it, there is no
way to let the system know that the resource is really not being used.

In the MANX SDB debugger, a programs _abort() (I think this is right)
procedure is called when you leave the debugger before the program exits.
Perhaps a simple-minded approach to kill would be to keep track of
the 'cleanup' routine in the task, or segment, and then have that called
before removing the task.  I am pretty sure this could be added to
a program compiled and linked under a specific compiler (such as Manx
version x.y), and then a kill utility could be supplied to remove
any tasks compiled with that compiler (version x.y and above).

Darin Johnson
djohnson@ucsd.edu