Xref: utzoo comp.sys.amiga:41688 comp.sys.amiga.tech:7596
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!texbell!sugar!karl
From: karl@sugar.hackercorp.com (Karl Lehenbauer)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: Suggestions for a kill command
Keywords: kill
Message-ID: <4362@sugar.hackercorp.com>
Date: 15 Oct 89 16:44:15 GMT
References: <1661@nigel.udel.EDU> <19591@ut-emx.UUCP>
Reply-To: karl@sugar.hackercorp.com (Karl Lehenbauer)
Followup-To: comp.sys.amiga.tech
Organization: Sugar Land Unix - Houston
Lines: 24

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