Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!oliveb!amiga!mitsumi!jimm
From: jimm@mitsumi.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga
Subject: Re: resource tracking problem
Message-ID: <272@mitsumi.UUCP>
Date: Fri, 18-Sep-87 13:53:41 EDT
Article-I.D.: mitsumi.272
Posted: Fri Sep 18 13:53:41 1987
Date-Received: Sun, 20-Sep-87 05:51:58 EDT
References: <5118@jade.BERKELEY.EDU>
Reply-To: jimm@mitsumi.UUCP (James Mackraz)
Organization: Mitsumi Technology Inc
Lines: 37

::
I haven't been following the resource tracking news very well, so please
forgive if this is old news.

If the idea is to be able to asynchronously kill some process (and presumably
all the little tasks it has spawned), don't forget about locks.  There
are semaphores that the process/task may hold or be enqueued for.  When a
process hold a lock, moreover, it is likely to be in the process of some
serious data (e.g., linked lists) manipulation.

Perhaps you may assume that if he (the process) isn't holding any locks, that
the only unstable data he might be leaving behind as he dies will also be
freed as one of his resources, but holding a lock on a shared data structure
implies the possibility of an unstable system if you kill him.  Note that
the data involved might not be public data structures (like parts of 
IntuitionBase) because the OS does a lot of such things while running
AS your process.

Processes spend some time "deep in the bowels" of an OS.  You need to decide
whether to try to extricate them or catch 'em on the way out.  I think
that some insight is to be gained by understanding how UNIX(r) handles
this stuff: a process takes a signal while it is blocked on I/O: wasn't
there some change between BSD 4.1 and 4.2 on the result?  Isn't it also
true that system calls typically run to completion before a process gets
switched out and is then vulnerable to taking a signal (except when it
is blocked for I/O, which is well-defined)?  So perhaps the perhaps UNIX
avoids the problem of a process taking a signal "deep in its bowels."

Always fun making a problem harder.  Perhaps that's why my thesis was
never written.

	jimm

-- 
	Jim Mackraz
	Mitsumi Technology, Inc.
	{amiga,pyramid}!mitsumi!jimm