jesup@cbmvax.UUCP (Randell Jesup) (06/19/88)
In article <8ccX.e4iTa1010IJOfY@amdahl.uts.amdahl.com> acs@amdahl.uts.amdahl.com (Tony Sumrall) writes: >being involved and even CATS (Randy Weiner). In fact, Leo wrote (in >article 3213@well.UUCP: >> Try this: >> >> AbortIO (ConsoleRead); >> WaitIO (ConsoleRead); >> Wait (1L << ConsoleRead -> io_Message -> mn_ReplyPort -> mp_SigBit); >> >> When I was writing Robotroff, there were occasions that I would need >>to AbortIO() a timer request so I could reconfigure things. I AbortIO()ed, >>then WaitIO()ed. I flushed it, right? [stuff by matt about making sure for some devices that the type == NT_MESSAGE] >Really? I know that SendIO() and BeginIO() are rather poorly documented >and they even say that their operation varies based on the device (RKM, >old version) but I can't remember *ever* seeing this in any source (other >than Matt's, perhaps). Leo's code is fine, if you care about the signal. You should NEVER write code that depends on the signal from the msgport telling you an IO request is done; use that signal as an indicator to CheckIO/WaitIO the message if you need to use it at all. WaitIO never does a Wait() if it doesn't need to. There's nothing to say that signal won't have been set by any of several other operations, like even DoIO(). DoIO() does a WaitIO internally, and if the message comes back REAL quick, the WaitIO may not wait. Remember, the whole idea behind CheckIO/ WaitIO was to hide the completion mechanism from people. (And also to support using one port for lots of IORequests.) Randell Jesup, Commodore Engineering {uunet|rutgers|ihnp4|allegra}!cbmvax!jesup