Welcome, Guest. Please login or register.

Author Topic: Cleaning IORequests dillema/CreateExtIO bug ?  (Read 950 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline JoseTopic starter

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2869
    • Show only replies by Jose
Cleaning IORequests dillema/CreateExtIO bug ?
« on: September 30, 2005, 02:34:33 PM »
Hey. Check out the following code...
Code: [Select]
#include <exec/types.h>
#include <exec/ports.h>
#include <exec/io.h>
#include <devices/timer.h>
#include <stdio.h>

#include <clib/exec_protos.h>
#include <clib/timer_protos.h>
#include <clib/alib_protos.h>

int main (int argc, char **argv)
{
struct MsgPort *ECPort;
struct timerequest *ECReq = 0;
BOOL TimerDeviceOpened = FALSE;

if (!(ECPort = CreateMsgPort()))
  printf (&quot;Couldn't create ECPort!\n&quot;);
else
  { if (!(ECReq = (struct timerequest *)CreateExtIO (ECPort, sizeof (struct timerequest))))
      printf (&quot;Coldn't create IORequest!\n&quot;);
    else
      { if (OpenDevice (&quot;timer.device&quot;, UNIT_ECLOCK, (struct IORequest *)ECReq, 0))
          printf (&quot;Couldn't open timer.device\n&quot;);
        else
          { TimerDeviceOpened = TRUE;

            ECReq->tr_node.io_Command = TR_ADDREQUEST;
            ECReq->tr_time.tv_secs = 0;
            ECReq->tr_time.tv_micro = 1000;

/*          DoIO ((struct IORequest *) ECReq);
*/        }
      }
  }

/* Clean Up */
if (TimerDeviceOpened)
  { if (!CheckIO((struct IORequest *)ECReq))
      { printf (&quot;Aborting...\n&quot;);
        AbortIO ((struct IORequest *)ECReq);
        WaitIO ((struct IORequest *)ECReq);
      }
    CloseDevice ((struct IORequest *)ECReq);
  }
if (ECReq)
  DeleteExtIO ((struct IORequest *)ECReq);
if (ECPort)
  DeleteMsgPort(ECPort);
}


Now if I change DeleteExtIO to DeleteIORequest (and CreateExtIO to CreateIORequest) the bloody thing works.
Is this a bug?
Note: I need to CheckIO first because this is only a scratch from my main program and in it some requests might have not been even sent, in wich case WaitIO will wait forever...
:pint:
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Cleaning IORequests dillema/CreateExtIO bug ?
« Reply #1 on: September 30, 2005, 03:48:40 PM »
Hmm. Both versions work just fine here, both SAS/C / C= amiga.lib and ppc-morphos-gcc / our amiga.lib replacement libabox.

I did spot a bug though: If CreateMsgPort fails, DeleteExtIO/DeleteIORequest is called with random pointer.
 

Offline JoseTopic starter

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2869
    • Show only replies by Jose
Re: Cleaning IORequests dillema/CreateExtIO bug ?
« Reply #2 on: September 30, 2005, 04:03:42 PM »
@Piru
Ok, corrected that bug:-)

As for the problem I described...
I'm not at home but I'm pretty sure it worked only as I described. I'm using VBCC and temporarily WinUAE with AmigaOS3.1.
 
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Thomas

Re: Cleaning IORequests dillema/CreateExtIO bug ?
« Reply #3 on: September 30, 2005, 04:08:48 PM »

I tried it with Dice C on WinUAE and don't see any difference between CreateExtIO and CreateIORequest. However I have some questions:

1. what happens for you if it fails ?
2. why do you use UNIT_ECLOCK ? IMHO it is too complicated to deal with these eclock values. UNIT_MICROHZ is much more convenient.
3. Why don't you use CreateIORequest ? It is recommended and as you say with it the program works as opposed to CreateExtIO.

Bye,
Thomas

Offline JoseTopic starter

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2869
    • Show only replies by Jose
Re: Cleaning IORequests dillema/CreateExtIO bug ?
« Reply #4 on: September 30, 2005, 04:16:00 PM »
@Thomas

Well, maybe I just missed out something..

1. what happens for you if it fails ?
It hangs. It seems that when using CreateExtIO, CheckIO won't be able to check correctly if anunsent request has returned or not.

2. why do you use UNIT_ECLOCK ? IMHO it is too complicated to deal with these eclock values. UNIT_MICROHZ is much more convenient.
Just a scratch I made from my main program to try to reproduce the bug.

3. Why don't you use CreateIORequest ? It is recommended and as you say with it the program works as opposed to CreateExtIO.
I will I was just wondering if this was a bug or not as I lost a bunch of time trying to track it down.

\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Georg

  • Jr. Member
  • **
  • Join Date: Feb 2002
  • Posts: 90
    • Show only replies by Georg
Re: Cleaning IORequests dillema/CreateExtIO bug ?
« Reply #5 on: September 30, 2005, 04:23:06 PM »
Quote
It hangs. It seems that when using CreateExtIO, CheckIO won't be able to check correctly if anunsent request has returned or not.


CreateExtIO likely (AROS version does) sets ln_Type to NT_MESSAGE. CreateIORequest does not.

If ln_Type is NT_MESSAGE CheckIO thinks request is in use/not finished and the abortio + waitio thing is done although request was never sent.

It's better to use some bool variable to remember whether a request was ever sent.

 

Offline JoseTopic starter

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2869
    • Show only replies by Jose
Re: Cleaning IORequests dillema/CreateExtIO bug ?
« Reply #6 on: September 30, 2005, 04:36:12 PM »
@Georg

That explains it.

"It's better to use some bool variable to remember whether a request was ever sent."

I was thinking about using CreateIORequest if the AmigaOS, AmigaOS4 and MOS versions of it work well (e.g. don't set NT_MESSAGE in ln_Type). Can anyone confirm this ?
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Cleaning IORequests dillema/CreateExtIO bug ?
« Reply #7 on: September 30, 2005, 06:00:23 PM »
CreateIORequest is standard exec function: All platforms set ln_Type to NT_REPLYMSG. If they don't, the OS is buggy.