How remove a Timer's IO request inside a soft interrupt?

On the AmigaE mailing list we have been discussing how (or even *if*) you should remove an IO message sent by the timer.device, in the case that you request a soft interrupt to be generated (instead of normal signal) when the IO message arrives at your port.

The autodocs quite clearly state that "When removing a known complete IORequest from a port, WaitIO() is the required. A simple Remove() is not enough." But this may have assumed you were just waiting on a signal on your message port, rather than having a soft interrupt generated. And it makes no mention of GetMsg().


And to make it worse, at least in the case where the message port only receives a single IO message from timer.device, before that message is re-used (for a repeating timer), then the code appears to work equally well whether you:

1. Never bother to remove the IO message from the message port. This must be the wrong approach.

2. Use WaitIO() inside the interrupt. This seems a bit hairy, since (a) if the interrupt really did wait then it would kill the whole OS, and (b) an interrupt is not a task (and therefore it does not have any signals to use or modify).

3. Use GetMsg() to remove the IO message. This would seem most likely to be the best answer, except for the autodoc's clear message that only WaitIO() is allowed.

I am guessing we need an AmigaOS dev to answer this for certain, but anyone else feel free to give your opinion too!

When a device replies to an IORequest, the ln_Type field is set to NT_REPLYMSG. When WaitIO finds ln_Type to be NT_REPLYMSG, it does not wait but simply removes the message from the port. So it is safe to call WaitIO if the message has already been replied. Of course you must make sure that your interrupt only fires for the IORequest you want to receive.

@thomas Quote:
Won't GetMsg() do exactly the same thing? If so, then why would WaitIO() be any better (autodoc recommendations aside)? GetMsg() would seem to be safer than WaitIO() inside an interrupt, since it cannot ever wait.

Quote:
Presumably the interrupt does NOT need to check the message type?

General device I/O is described here
http://wiki.amigaos.net/index.php/Exec_Device_I/O

When it comes to Timer Device you can find docs here
http://wiki.amigaos.net/index.php/Timer_Device

Software interrupts are described here
http://wiki.amigaos.net/index.php/Exe ... rupts#Software_Interrupts

Some of this material may need polishing but I think it should answer your questions.

P.S. I anybody wants to help modernize the code samples on the wiki please feel free to send me the corrected text via email.

@ssolie
OK, thanks. (I had thought that I'd already checked the AmigaOS Wiki some months ago, but either I missed it or else it got added later.)

It appears that GetMsg() is the recommended way to remove the timer IO message from inside a soft interrupt:
Quote:

BTW, that code has a whole section wrongly commented-out, due to a missing end-of-comment:
Quote:

Something else I noticed is that I am using SendIO() as I saw used in Kas1e's interrupt timer example code, but the wiki shows BeginIO(). It's not clear to me whether this makes much difference:

BeginIO() seems to not clear flags (like the Quick bit), where-as SendIO() does, but I don't see any flags being set in the example, so I'm not sure why BeginIO() is used, unless the flags are ignored (in which case it is a very tiny optimisation)?

DoIO wait for IO to be done while BeginIO(), sends the commands only, the result will be received latter when it was accurately was done.

You should probably do not wont to be stuck in the interrupt too long, better use BeginIO.

@LiveForIt
Please re-read what I wrote. I never mentioned DoIO! This is about *SendIO* vs BeginIO.

Quote:
Not any more it doesn't.

These functions are also explained on the wiki:
http://wiki.amigaos.net/index.php/Exec_Device_I/O#Using_A_Device

In the context of the timer.device the quick I/O mechanism makes no sense anyway. You have to wait for the reply...

@ChirsH

After a walk around the block I realized that my comment did not make any sense, it is not really possible to delete forum posts, so instead I corrected the comment by replaced SendIO() whit DoIO(). While I ended up not answering your question at least my answer was correct, and not total bs.

I do remember something about quick flag, but can’t remember what it was; all I know is that it is something that is handled whit in the device itself.

Quote:
Check this out http://wiki.amigaos.net/index.php/Exec_Device_I/O#Using_A_Device

So the correct thing to say is that BeginIO is the hybrid between DoIO and SendIO, it might wait until operation is completed or it might not, if the IOF_QUICK is clear then BeginIO acts the same way as SendIO() if, IOF_QUICK is set then it acts as DoIO().

So her is the user case:
Application should not need to wait for reply message if IO operation was performed quickly.
Application should not be blocked if IO operation if it was not completed quickly.

@ssolie Quote:
You only changed one BeginIO to SendIO... there is still one BeginIO remaining.

Quote:
I reverted the change. I just realized the point of the example is to show you the use of BeginIO() from within a software interrupt. My mistake.

Instead, I have added a note regarding BeginIO() here: http://wiki.amigaos.net/index.php/Exec_Device_I/O#Using_A_Device

That should clear everything up now.

@ssolie
Are you *sure* that BeginIO() is a good idea within an interrupt? The documentation specifically says "BeginIO() may allocate memory, wait or perform other functions which are illegal or dangerous during interrupts." I know that the audio & timer devices are supposed to be special cases, but I don't see any advantage over SendIO() for interrupts.

Quote:
I'm not sure which note you added regarding BeginIO.

Quote:
The point of the example was to demonstrate the rather subtle differences between SendIO() and BeginIO(). The example also shows you it is OK to start a timer from a soft interrupt. This is a special exception of course but something that was obviously under documented.

Please review Using a Device again. I added the "BeginIO() Side Effects" note.

I have also just added a section on using timer.device from interrupts in the Timer Device documentation.

I hope that is enough for now.