[comp.sys.amiga] resource tracking problem

jimm@mitsumi.UUCP (Jim Mackraz) (09/18/87)

::
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

bryce@zen.UUCP (09/24/87)

> 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.

Slightly off the subject... ever crashed a task that had MenuVerify
turned on?  Any attempt to use menus will send a message to a task
that is no long able to respond. "poof"

Neither Exec nor Intuition make any attempt to invalidate verify fucntions,
gadgets or anything else for crashed tasks (though they could).

Something not mentioned in the stacks and stacks of Intuition verify
warnings is that it is a poor idea to have a low priority task use any sort
of verify.  The verify is done on the task's schedule (of course) and can
be locked out for long periods of time.  The mouse may end up locked until
your compile finishes :-).


 
|\ /|  . Ack! (NAK, ENQ, SYN)
{o O} . 
 (") 	bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce
  U	How can you go back if you have not yet gone forth?