Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Whaddya do in ioCompletion routine?
Keywords: ioCompletion Asynchronous
Message-ID: <a3^^h2.t35@smurf.sub.org>
Date: 11 Mar 91 18:04:17 GMT
References: <49791@apple.Apple.COM> <1991Mar7.204208.20535@jato.jpl.nasa.gov> <1991Mar10.231236.21526@ni.umd.edu>
Organization: University of Karlsruhe, FRG
Lines: 34

In comp.sys.mac.programmer, article <1991Mar10.231236.21526@ni.umd.edu>,
  zben@ni.umd.edu (Ben Cranston) writes:
< Anybody seen the behaviour with ASynch _Read calls:  whatever is in D0 when
< the IO completion routine returns gets returned to the mainline in D0 rather
< than the IO result for the operation itself?  I tend to code a check in the
< mainline:
< 
<         LEA  IOPB,A0
<         _Read  ASync
<         BEq.S  around
<         <ERROR DETECTED HERE>
< around  ;
< 
Ignore the "error" returned from the _Read call. The D0 there might contain
literally anything.

The only reliable place where you get the error reported correctly is in the
completion routine.
< 
< Also, anybody ever seen an asynch _Open and/or _Read return to the
< mainline with D0 = 1 and ioResult(A0) = 2????  I've only seen this when
< AppleShare Server was running in foreground...

It's _asynchronous_. You don't have any guarantee that it returns in the next
five minutes, much less immediately. This only holds for SCSI, and only right
now because Apple seems to be still working on a reasonably intelligent SCSI
Manager.

The async call is completed iff the ioResult field is <= 0. Don't touch the
parameter block before that time.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330)   \o)/