Xref: utzoo comp.unix.wizards:24237 comp.unix.internals:2148 Path: utzoo!utgpu!news-server.csri.toronto.edu!utcs.toronto.edu!cks Newsgroups: comp.unix.wizards,comp.unix.internals From: cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) Subject: Re: Help with 4.3 mod to kill uninteruptable procs. Message-ID: <1991Feb23.191333.22577@jarvis.csri.toronto.edu> Organization: Ziebmef home away from home References: <1991Feb19.001941.29928@lynx.CS.ORST.EDU> <1991Feb21.152845.29019@cbnews.att.com> <305@orac.pgh.pa.us> Date: 24 Feb 91 00:13:34 GMT Lines: 22 pat@orac.pgh.pa.us (Pat Barron) writes: | This has been the case forever (well, at least since V7) - when you come | out of a sleep(), you *must* check that the reason you were sleeping is | no longer true.... Unless your code is careful to make sure that it is the only one which can consume the particular resource which it is sleeping on; consider, for example, a system call tracing facility, where you have a sepperate process that drains the trace buffers into a disk file. Also, one common strategy for dealing with the 'other people may have taken this resource already' is while (!resource) sleep(resource, priority); If you whack the process and get it to come out of the sleep, and the resource isn't available, the process will just go back to sleep, which isn't particularly helpful for the original poster's purpose. -- V9: the kernel where you can do fgrep */*.[ch] and not get "Arguments too long". cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks Brought to you by Super Global Mega Corp .com