Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!bryce
From: bryce@zen.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: resource tracking problem
Message-ID: <3935@zen.berkeley.edu>
Date: Thu, 24-Sep-87 03:48:39 EDT
Article-I.D.: zen.3935
Posted: Thu Sep 24 03:48:39 1987
Date-Received: Sat, 26-Sep-87 09:57:35 EDT
Sender: news@zen.berkeley.edu
Organization: Tubular Transport, Inc.
Lines: 25

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