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
