Path: utzoo!dciem!nrcaer!fts1!julie!mcr
From: mcr@julie.UUCP (Michael Richardson)
Newsgroups: comp.sys.amiga.tech
Subject: Aborting TimerReq (answer and a question)
Keywords: timer.device AbortIO() WaitIO() Wait()
Message-ID: <1498.AA1498@julie>
Date: 25 Nov 89 09:31:10 GMT
References: <4499@blake.acs.washington.edu>
Followup-To: comp.sys.amiga.tech
Organization: Sandleman Software Works' Debugging Department, Ottawa, ON
Lines: 56

In some message which my not quite real news software doesn't know how
to reply to, Dale Larson wrote:
>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.

  Well --- the edition of the RKM and autodocs that I had was 1.2. It
makes no mention of AbortIO() on a timer.device request. It seems that
the 1.3 manuals do make mention...

>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

  Hmm. Some my problems with it might have stemmed from the fact
that I wasn't always WaitIO()ing my aborted requests... This seems to
have cleaned up some of my problems, but it is possible that there are
still other problems caused by whatever it is that you are seeing...

>to clear some bit or another.  The following code segment, however, has
>been working for me:
  [code that Wait()s after the WaitIO() removed]

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

  Hmm. I believe that WaitIO() doesn't call Wait() if the request has
already arrived. I would expect that it checks the ln_Node member for
NT_REPLY, and if found Remove()s the entry from whatever message queue
it is on. If not it Wait()s for the signal, and does the check again.
Why a Wait() _after_ the WaitIO() request doesn't block, I'm not sure...
But I can see that if the message has already arrived, replacing WaitIO()
might not work correctly....



--

  :!mcr!:
  Michael Richardson
                    Amiga
             v--------+
 HOME: mcr@julie.UUCP | SCHOOL: mcr@doe.carleton.ca
 Fido: 1:163/109.10<--+ WORK: michael@fts1.UUCP