Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site unicus.UUCP
Path: utzoo!mnetor!yetti!unicus!sat
From: sat@unicus.UUCP (S.A. Thurlow)
Newsgroups: comp.sys.amiga
Subject: Re: "kill"
Message-ID: <935@unicus.UUCP>
Date: Mon, 31-Aug-87 10:13:41 EDT
Article-I.D.: unicus.935
Posted: Mon Aug 31 10:13:41 1987
Date-Received: Wed, 2-Sep-87 00:38:51 EDT
References: <1708@amiga.amiga.UUCP> <581@sugar.UUCP>
Reply-To: sat@unicus.UUCP (S.A. Thurlow)
Organization: Unicus Software Inc., Toronto, Ont.
Lines: 56
Keywords: memory fragmentation

In article <581@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>Isn't there a "end task" entry in the task structure? Is that entry
>called in a way compatible with 'C'? If not, how much glue would you
>need? Can't you implement a "kill" program that calls this routine?

True, but this is not as good as it seems.  You see, if I don't set
things up right in my task structure, your kill won't free the memory
and close the devices I've allocated.  It is the application
programmer's responsibility to set up and maintain the "end task" entry
in the task structure.  (I wish I could give more information here, but
my RKM is at home).

>The other thing you need to do then is add a "set kill action" routine
>to the 'C' library that sticks the address of a specified routine into
>that slot (this routine, of course, has to end with a terminate task
>call...)?

Yeah, BUT AllocMem's, open windows, open devices, etc. are still not
tracked.  You would need to redo the resource management routines so ALL
memory and device allocations are tracked and can be undone by the "end
task."  The OS really should do this to guarantee that kill will always
have the same affect. As it is now, a kill will behave differently for
different applications.  It is  the application programmer's (or his
compiler's) responsibility to make sure things are set up right for the
kill to work.  How many application programmers are there out there? How
many C compilers?  How many adventurous programmers who are going to
muck with task structure behind the OS's back?  Good luck in getting
everyone to cooperate.

>That's much better than having to watch for SIGB_CTRLC all through your
>code. Existing tasks (which presumably just "kill myself") would leave
>junk all over the place... but at least they'd be gone.

True.  What does intuition do with windows/screens that don't belong to
any task?

>This would also take care of nerds who forget to make sure they call
>their cleanup routines before exiting.

The resource allocations can be tracked by writing wrappers functions
for the allocation routines, and hoping that everyone uses these
wrappers.  Any ideas on how to enforce this?  I guess a really smart
compiler could substitute rom calls with a call to the appropriate
wrapper function.

>-- 
>-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter
>--                  U   <--- not a copyrighted cartoon :->


-- 
Scott A. Thurlow					Unicus Corporation
InterNet:	sat@Chi.Unicus.COM			(on a good day)
UUCP:		{uunet!mnetor,utzoo!utcsri}!unicus!sat	(on a bad day)
ARPA:		uunet!mnetor!unicus!sat@Seismo.CSS.GOV	(on a REALLY bad day)
BITNET:		THURLOW@UTORGPU				(you figure this out)