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?