Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!caesar.cs.montana.edu!ogccse!blake!dlarson
From: dlarson@blake.acs.washington.edu (Dale Larson)
Newsgroups: comp.sys.amiga.tech
Subject: Aborting TimerReq (answer and a question)
Keywords: timer.device AbortIO() WaitIO() Wait()
Message-ID: <4499@blake.acs.washington.edu>
Date: 17 Nov 89 17:55:04 GMT
Organization: The Evergreen State College,  WA
Lines: 48

/*  eat this? */

A few weeks ago, I posted a message about a problem with aborting a
timer request.  The only response I recieved indicated that doing
so is not possible.  I have found a kludgy way of aborting the request, 
and would like to know why it seems to be necessary.  If I'd saved that
address for sending bug reports to, I'd send it.
 
From: lsuc!nrcaer!julie!mcr@neat.ai.toronto.edu (Michael Richardson)
>>Is the only way to reuse my timer request to close down the device and port
>>and re-open them???  Or have I (HOPEFULLY!) done something stupid again?
>  Look at the entry for timer.device again --- notice the lack of support
>for AbortIO()?
>  You can't abort the timer.device.
>  Everyone seems to anyway though... and it worked for me, until a friend
>pointed out that you can't abort it.

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."

As stated in my original message (to which I have recieved no other replies)
I cannot get things to work properly with a simple AbortIO()/WaitIO() pair.
The WaitIO() always returns error IOERR_ABORTED (or whatever) and fails
to clear some bit or another.  The following code segment, however, has 
been working for me:

			if(AbortIO((struct IORequest *)TimerReq))
			{
				close_down("AbortIO(TimerReq) Error!");
			}
			if(error=WaitIO((struct IORequest *)TimerReq))
			{
				Wait(1<<TimerPort->mp_SigBit);
			}

If I replace the WaitIO() with the Wait(), however, something else is broken
(it waits forever if I recall correctly, it's been a few weeks and my notes
are jumbled).

Can anyone shed any light for me?

-- 
	    A lack of prior planning on the part of any programmer 
		       always constitutes an emergency.
	
           Digital Teddy Bear      dlarson@blake.acs.washington.edu