Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!info-vax From: info-vax@ucbvax.ARPA Newsgroups: fa.info-vax Subject: Cancelling another process' I/O requests Message-ID: <9018@ucbvax.ARPA> Date: Fri, 12-Jul-85 18:15:27 EDT Article-I.D.: ucbvax.9018 Posted: Fri Jul 12 18:15:27 1985 Date-Received: Sat, 13-Jul-85 13:33:48 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 28 From: GKN%OAK.SAINET.MFENET@LLL-MFE.ARPA Hard (if not impossible) to do without being in the context of the process involved, since the CCBs live in P1 space and there is a pending I/O count through a channel that EXE$CANCEL and friends insist on decrementing. If you don't mind the pending I/O count through another process' channel being wrong (and I don't think that this is a good idea; it'll prevent the process from being deleted) then you could get brave and remove the IRP from the UCB's I/O queue and stick it on the I/O post processing queue. But this is also nasty because some device drivers like to know when an I/O request gets cancelled even if it hasn't been started yet. It's still best to queue a special kernel AST to the process in question to clobber the I/O request. gkn ------------------------------------------ Arpa: GKN%OAK.SAInet@LLL-MFE USPS: Gerard K. Newman Science Applications International 800 Oak Ridge Turnpike Oak Ridge, TN 37830 AT&T: (615) 482-9031