Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!usc!apple!oliveb!amiga!kodiak
From: kodiak@amiga.UUCP (Robert R. Burns)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Aborting TimerReq (answer and a question)
Keywords: timer.device AbortIO() WaitIO() Wait()
Message-ID: <4883@amiga.UUCP>
Date: 21 Nov 89 18:40:01 GMT
References: <4499@blake.acs.washington.edu>
Reply-To: kodiak@batgirl.UUCP (Robert R. Burns)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 34

In article ... dlarson@blake.acs.washington.edu (Dale Larson) writes:
)Page B-68 of the printed 1.3 AutoDocs (the entry for
)timer.device/TR_ADDREQUEST) says:
)
)"The message may be forced to finish early with an AbortIO()/WaitIO() pair."

I abort TR_ADDREQUEST requests as follows (here follows C version of asm
code used to abort the time request that causes keys to repeat in the
input device task):

	AbortIO(TimerReq);
	WaitIO(TimerReq);

Notes:
    1.  the result of AbortIO is always meaningless.  For example, if
	the timer has already handled the TR_ADDREQUEST, it would
	report that the AbortIO failed -- but you don't care because
	you're doing a WaitIO next anyway.
    2.  the result of WaitIO is meaningless here.  What do you care whether
	the timer request was satisfied or aborted: your code flow is
	only interested in retrieving the TimerReq for reuse, which it
	has done successfully at this point.

[he then describes some problems and his solution]

)The WaitIO() always returns error IOERR_ABORTED (or whatever) and fails
)to clear some bit or another.

I don't know what bit you're talking about.
-- 
Bob Burns, amiga!kodiak						 _
	| /_  _|. _ |		   Commodore __			|_) _ |_  _ )'
	|<(_)(_)|(_\|<		    /\ |  ||| _` /\		|_)(_\| )(_\ |
	| \ Software		___/..\|\/|||__|/..\___			 Faith