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