Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: Question on AbortIO() and WaitIO() Message-ID: Date: 29 May 91 02:43:18 GMT Article-I.D.: overload.dillon.8069 References: <28630@uflorida.cis.ufl.EDU> <21757@cbmvax.commodore.com> Organization: Not an Organization Lines: 54 In article oliphant@telepro.UUCP (Mike Oliphant) writes: >In article <21757@cbmvax.commodore.com> carolyn@cbmvax.commodore.com (Carolyn Scheppner - CATS) writes: >.. >>If you KNOW there is an outstanding request, I believe the best >>action is: >> >>if(!CheckIO(ioreq)) AbortIO(ioreq); >>WaitIO(ioreq); > >The CheckIO() is EXTREMELY important with the A2232 serial card - it doesn't >like you aborting requests that have been satisfied. In fact, it seems that This is a bug in the A2232 serial.device It *has* been fixed in alphas of the next release, along with a few other bugs. >even the CheckIO() safety measure is not enough with this card. I've found >this method solves the problem: > > NiceAbort(ioreq) > struct IORequest *ioreq; > { > Forbid(); > if(!CheckIO(ioreq)) AbortIO(ioreq); > Permit(); > WaitIO(ioreq); > } I'm not sure this will work. If the A2232 serial.device uses a SoftInt instead of a process to handle returning requests, then all the Forbid()/Permit() does is reduce the window of oportunity. But it does sound like a good temporary solution to the problem! You need to use Disable/Enable though, however bad that may sound. >-- >Mike Oliphant telepro!oliphant@herald.usask.ca or herald!telepro!oliphant > FidoNet: (1:140/91) - ZMH only >* >* Call TelePro, the development system for DLG Professional >* >* Phone: +1 306 249 2352 2400/9600/14400 bps HST - FidoNet: (1:140/90) >* +1 306 652 2084 300/1200/2400 bps >* -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA