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 request
Message-ID: <9079@ucbvax.ARPA>
Date: Mon, 15-Jul-85 17:25:10 EDT
Article-I.D.: ucbvax.9079
Posted: Mon Jul 15 17:25:10 1985
Date-Received: Wed, 17-Jul-85 06:42:30 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 31

From: GKN%OAK.SAINET.MFENET@LLL-MFE.ARPA




Umm, er, ah... boy, does my foot taste good!

As it turns out, if you're willing to ignore FCP/ACP type I/O requests
you CAN cancel another process' current I/O request.  What you have to
do amounts to not a whole lot of code:

        Locate the UCB of the device for which you wish to cancel I/O
        SETIPL to UCB$B_FIPL
        Grab UCB$L_IRP and stick it in R3
        Grab the channel index out of the IRP and stick it in R2
        Grab the PCB out of the IRP and stick it in R4
        Stick your favorite reason code in R8 (CAN$C_CANCEL or _DASSGN)
        Call the driver's cancel I/O routine (DDT$L_CANCEL)

IOC$IOPOST takes care of the stuff that requires process context, as it
turns out.  Oh well, I learned something new this time.

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