Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
144 user(s) are online (125 user(s) are browsing Forums)

Members: 0
Guests: 144

more...

Support us!

Headlines

 
  Register To Post  

(1) 2 »
Problems with PIPE: [SOLVED!]
Just can't stay away
Just can't stay away


See User information
What's wrong with this code?? It compiles with "gcc -o apipe amigapipe.c -lauto"...

//********* amigapipe.c *********

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <fcntl.h>

#include <proto/dos.h>


int main()
{
BPTR fd[2];
const char *strings[] = {"hello\n", "how are you\n", "see you later\n"};
BOOL end = FALSE;
int nbytes;
char readbuffer[1024];
int flag, i;

//amiga_pipe(fd);
fd[1] = IDOS->Open ("PIPE:testpipe", MODE_NEWFILE);
fd[0] = IDOS->Open ("PIPE:testpipe", MODE_OLDFILE);
if (fd[0] == NULL || fd[1] == NULL)
exit(-20);

IDOS->SetBlockingMode (fd[0], SBM_NON_BLOCKING);

for (i = 0; i<3; i++)
{
nbytes = IDOS->Write(fd[1], strings[i], strlen(strings[i]));
printf("bytes written to the pipe: %d\n", nbytes);
printf("string written: %s\n", strings[i]);
}
//IDOS->Delay(50);
while(end != TRUE)
{
nbytes = IDOS->Read(fd[0], readbuffer, sizeof(readbuffer));
if (nbytes <= 0)
end=TRUE;
else
{
readbuffer[nbytes] = 0;
printf("received from pipe:\n%s\n", readbuffer);
}
}
if (nbytes == -1)
printf("ERROR!\n");

//amiga_closepipe(fd);
IDOS->Close(fd[0]);
IDOS->Close(fd[1]);

return(0);
}

When I run it, the writing part is fine, but the reading part just returns an error without reading anything. If I remove the "SetBlockingMode" line, the reading is also fine, but then the program hangs on the next Read() instead of just returning 0 and letting the program finish. This is obviously exactly what I want to avoid...

I have tried many many things to change it: Inserting Delay(), opening with "PIPE:testpipe/NOBLOCK", opening with MODE_READWRITE etc... and nothing seems to change the fact, that the non-blocking functionality just doesn't work...

Please, I need a smart person to tell me, how to solve this!


Edited by alfkil on 2010/3/1 1:22:28
Go to top
Re: Problems with PIPE:
Just popping in
Just popping in


See User information
@alfkil

What exactly are you trying to do ? IMHO reading and writing to the same pipe within the same execution thread has no sense at all (use ?) since at some point the write buffer will be full (and your application will Wait() forever for someone to read it). Here's a link to a thread on utilitybase with a working pipe example.

Edit: AFAIR, the writer must close the pipe for the reader to get an EOF, that's probably why your program hangs (in the version with blocking).

Go to top
Re: Problems with PIPE:
Amigans Defender
Amigans Defender


See User information
@alfkil
Quote:
Please, I need a smart person to tell me, how to solve this!

Read the file SYS:Documentation/handlers/queue-handler.doc because it will explain a lot of the details regarding using pipes on AmigaOS.

The file is included standard with AmigaOS 4.1 Update 1. I'm not sure where the file is in previous releases.

ExecSG Team Lead
Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@ssolie

Thanks, but I already read though that file a gazillion times, and as far as I can see, from the description it gives, there is a BIG FAT BUG in queue-handler... or at least what I would call a "discrepancy" btw the documentation and the actual API; namely that the /NOBLOCK clause doesn't work at all when applied to a reading end of the pipe, and that IDOS->SetBlockingMode() also fails to fulfill it's purpose (on the writing end it might work, I don't know)... In both cases IDOS->Read(pipehandle, ...) will return only errors and no data, although the filehandle seems to be fine otherwise.

I would like if anyone could confirm this... Also, if it is really a bug, I would like to send a bug report, but I don't know where to send it.

EDIT: Usually in these kinds of situations, it turns out, that I'm just a big fat pinhead who has overlooked something totally obvious to the person of average intelligence. Hence my need for confirmation

Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@centaurz

Hmm... I replied to your msg yesterday, but the reply seems to have vanished. I'll retry:

Of course I'm not going to use a pipe for read/write in the same process. This is just a simplified test app to see, if the pipe itself will actually work or not.

The reason it blocks is because that's how it's supposed to do (at least that's how it works on Mac OS X 10.4 with the unix 'pipe()'). But it is ALSO supposed to react to setting a /NOBLOCK flag, that makes this behavior go away (which means, that the subsequent call to Read would return immediately with no data). The last thing is what I cannot get to work. From the documentation it is supposed to work, so I figure there's a bug somewhere (read my other post).


Edited by alfkil on 2010/2/22 21:33:13
Go to top
Re: Problems with PIPE:
Supreme Council
Supreme Council


See User information
@alfkil

You can use GetFileSize() on the pipes filehandle, and this will return the amount of data waiting to be read.

It doesn't fix your current problem, but perhaps something to consider...

Simon

Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@Rigo

Ok, thanks, I'll try it!

Go to top
Re: Problems with PIPE:
Just popping in
Just popping in


See User information
@alfkil

SetBlockingMode() is not a void function.

Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@colinw

Hmm... What is it returning? True/false or smth else? I can't check right now, I'll look at it this weekend.

Still this doesn't explain why Open("PIPE:testpipe/NOBLOCK", MODE_OLDFILE) doesn't work (it returns a valid filehandle, but when reading from it, it returns only errors).

Go to top
Re: Problems with PIPE:
Quite a regular
Quite a regular


See User information
@alfkil

I didn't check the Autodocs yet, but shouldn't a non blocking pipe return reading error when it is empty ?

Back to a quiet home... At last
Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@abalaban

Yes it should! But this one returns an error even when it is NOT empty, that's the problem...

Again: Where do I go to file a bug report on an Amiga OS component?

EDIT:
And also: Could somebody please just copy the code, compile and run it to confirm, that it is not just a local problem on my system? You don't need to know anything about, what the code does, all you need is to have the official OS 4.1 SDK installed, follow the compiling instructions I gave, run with 'apipe', and then if you would post the output you get to this thread. It should take about 2 minutes to do. Please??... Thanks!


Edited by alfkil on 2010/2/24 13:09:27
Edited by alfkil on 2010/2/24 13:09:59
Edited by alfkil on 2010/2/24 13:10:39
Edited by alfkil on 2010/2/24 13:11:33
Go to top
Re: Problems with PIPE:
Quite a regular
Quite a regular


See User information
@alfkil

Quote:

alfkil wrote: Hmm... What is it returning? True/false or smth else? I can't check right now, I'll look at it this weekend.


Okay took five minutes to read the dos.library/SetBlockingMode() Autodoc so here are two excerpts that seems to be of interest here :
RESULT
    old_mode 
-- This is either the old blocking mode in effect
        before you selected the 
new mode, or or -(see notes). 
        If 
it is 0then the new mode could not be selected
        
possibly because the handler does not support the 
        SetBlockingMode
() function.
And
If a stream is operating in non-blocking mode and the requested Read()
    or 
Write() action cannot be performed immediatelyit will return
    
with result == -and IoErr() == ERROR_WOULD_BLOCK.

I can't test your code I'm not at home and furthermore my A1 has gone for a CPU Module repair :-/

There is also an important note
Not all file systems and handlers will support this functionality.
    
Always check the return code of this function and IoErr().

Back to a quiet home... At last
Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@abalaban

Thanks for the info, I'll check it out when I get home this weekend.

It still doesn't explain why /NOBLOCK doesn't work in reading mode, though.

Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@alfkil

I tried compiling and running your code, and I get the same results.

I added some extra debug printout which showed that:

- GetFileSize() returns 32 (the combined length of the written items) both when called before and after the read attempt.

- SetBlockingMode() returns an old mode of 1 (SBM_BLOCKING) as expected.

- IoErr(), when called just after the read attempt (which returns -1), returns ERROR_WOULD_BLOCK.

I even tried moving the Close() of the written end of the pipe (fd[1]) up before the read attempt, which changed nothing.

I have not done much Amiga programming, and my C may also in general be a bit rusty, but I agree, this does seem strange to me too.

Best regards,

Niels

Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@nbache

One can always count on you, Niels! Thanks for the info!

Go to top
Re: Problems with PIPE:
Quite a regular
Quite a regular


See User information
@nbache

Strange indeed, to finalize the test can you change the line
nbytes IDOS->Read(fd[0], readbuffersizeof(readbuffer));

to
nbytes IDOS->Read(fd[0], readbuffer32);


and see if it change something ?

Back to a quiet home... At last
Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@abalaban
Quote:
abalaban wrote:
@nbache

Strange indeed, to finalize the test can you change the line
nbytes IDOS->Read(fd[0], readbuffersizeof(readbuffer));
to
nbytes IDOS->Read(fd[0], readbuffer32);
and see if it change something ?

Done, no change.

Best regards,

Niels

Go to top
Re: Problems with PIPE:
Quite a regular
Quite a regular


See User information
@nbache

Then there is certainly a problem somewhere maybe in the code above, maybe in the system I don't know. Anyway blocking mode or not, reading 32 bytes out of a streraam containing 32 bytes should always work, shouldn't it ?

Back to a quiet home... At last
Go to top
Re: Problems with PIPE:
Not too shy to talk
Not too shy to talk


See User information
@nbache

What happens if you do

nbytes = IDOS->Read(fd[0], readbuffer, 1);

?

Go to top
Re: Problems with PIPE:
Just can't stay away
Just can't stay away


See User information
@thomas

No difference.

Go to top

  Register To Post
(1) 2 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project