ranjit@grad2.cis.upenn.edu (Ranjit Bhatnagar) (10/15/89)
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. Note that this is not quite the same as lowering the priority of a process, since even at minimum priority, a process will continue to eat time on an otherwise idle system. OK, you say, if the system is otherwise idle, why do you care if the runaway process is eating time? Well, I may suspect that it's about to do something dreadful (oh no, I forgot to put an upper limit on the clear-memory loop) and I want it to STOP. The psychological advantage of the terms 'suspend' and 'resume' is that the user will not expect resources to be freed, and will not complain when they aren't. Of course, if you're not careful, you'll end up with csh job control... - ranjit "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
djohnson@beowulf.ucsd.edu (Darin Johnson) (10/15/89)
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
karl@sugar.hackercorp.com (Karl Lehenbauer) (10/15/89)
In article <19591@ut-emx.UUCP> jonabbey@walt.cc.utexas.edu (Jonathan Abbey) writes: >Actually, I don't think it would be all that difficult.. all it would >take (Quick! Check the RKM Jon:... got it!) would be an expansion to the >Task structure similar to tc_ExceptCode and tc_TrapCode, perhaps tc_ExitCode >with an accompanying tc_ExitData (containing an intuition RememberKey, for >instance), that points to a routine to be executed upon exit from a task, >either through a kill signal, normal exit from main code, or an unsalvageable >task crash. This is pretty much already in there. There's a control-C signal bit. Get everyone to start supporting it, and I guess you'd need a control-C-sender for workbench-launched tasks. And the sorts of errors that the processor can detect, like illegal instruction, odd address (where relevant) and such can already be trapped, too. One thing is, when your application communicates programs and such, it can be very tricky to get everything to safely back out anyway. [Followups to comp.sys.amiga.tech] -- -- uunet!sugar!karl "There is hopeful symbolism in the fact that -- flags do not wave in a vacuum." -- Arthur C. Clarke -- Usenet access: (713) 438-5018
gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (10/18/89)
The really silly thing is that the O/S already knows that we have a resource, that is its job, why can't a sys_exit() routine be supplied with DOS that does all of the cleanup? The UN*X notion of everything being a file that the process must open or close certainly make life simpler. Why can't each resource in amiga-dos have a resource address that is put into an array of per process resource pointers at the time that it is allocated? An O/S routine call of the form add_resource(TaskPtr, ResourcePtr) would add a resource to the list of the PROCESS indicated by the TaskPtr. When a process exits (tasks calling sys_exit() cause a cooresponding per-process task counter to be decremented, when it is zero, process exit work is done), all associated cleanup could be done by having the O/S do somthing like the following for (i=0; i < TaskPtr->resource_cnt; ++i) (*TaskPtr->res_list[i]->freeproc)(TaskPtr, TaskPtr->res_list[i]) Presto, everything always gets cleaned up! What's the problem with with something like this? Seems rather silly for us to be banging our heads against the wall and rebooting all the time when this kind of stuff is what O/S's are supposed to do for us! Gregg Wonderly -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)