Hi, using select solved the problem ... I was not using wait/waitpid ... it works fine now :) Thanks for all the help. Really appreciate it. Best Regards, Saurabh On Dec 8, 2007 2:12 PM, Steve Graegert <graegerts@xxxxxxxxx> wrote: > On Dec 7, 2007 12:27 AM, Saurabh Sehgal <saurabh.r.s@xxxxxxxxx> wrote: > > Hi, > > > > Thanks for the reply .. right now, i was reading and checking for the > > errno EAGAIN, but my loop would prematurely exit. I later found out > > that the errnor returned by read was ECHILD ... looking at the read(3) > > manpages ... this errno is not mentioned > > > > But since the process that is supposed to write to the pipe is a > > forked processs .. does that change anything ? > > Sorry for the delay... > > Looks like you have other problems with your code. I suppose you're > calling wait(2)/waitpid(2)? Could you please post the code in > question? Otherwise I fail to see what could be wrong. > > \Steve > > PS: Please, do not top post as it makes it diffcult to follow the > conversion. Thanks. > > > > On Dec 6, 2007 4:29 PM, Steve Graegert <graegerts@xxxxxxxxx> wrote: > > > > > > On Dec 6, 2007 9:14 PM, Saurabh Sehgal <saurabh.r.s@xxxxxxxxx> wrote: > > > > Hi, > > > > > > > > I had a basic question about read . I have a file descriptor marked > > > > with non blocking I/O , and I want to read data from the file > > > > descriptor. This file descriptor is the read end of a UNIX pipe. > > > > > > > > The process that the pipe reads from is a very slow process. Hence I > > > > need to poll and keep on trying to read from the fd until the process > > > > has actually written something to the pipe. I execute read while the > > > > errno condition EAGAIN is true. Will this ever result in an infinite > > > > loop ? (lets say the remote process dies and doesnt write anything to > > > > the pipe, will I go into an infinite loop since I am polling while > > > > EAGAIN is true ?). > > > > > > Hi, > > > > > > I'd suggest taking a look at select(2) which allows for the > > > specification of a timeout. Use pselect(2) if you are waiting for a > > > signal as well as data from a file descriptor or otherwise the > > > select(2) call may block indefinitely due to a nasty race condition > > > that may occur. > > > > > > To your question: There are actually a couple of reasons why your > > > process would or would not run indefinitely in that loop. There are > > > also a couple of other errors read(3) can return that might cause your > > > condition to return false, thus breaking the loop (if I understood > > > correctly, code example is welcome). What about EINTR which is > > > returned when the call was interrupted by a signal before any data was > > > read? (Please note that for a FIFO or pipe it will never return EINTR > > > if any data has been read.) > > > > > > \Steve > > > > > > -- > > > > > > Steve Grägert > > > DigitalEther.de > > > > > > - To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
