Hi, Laurent, I tried your suggestion in pipetest-server.c
" The generally accepted, portable way to handle sequential reads on a FIFO is for the reader to also open the writing end of the FIFO (and do nothing with it) for as long as it wants to read." It did not work. I am not sure whether it is possible to open same FIFO, and use one as reader, and use second as writer, in same user process. Do you have sample codes to demo your suggestion? Thanks, Jian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Laurent Bercot Sent: Wednesday, June 01, 2011 11:00 PM To: [email protected] Subject: Re: named pipe is borken and proposed fix > The problem is that FIFO is a special file type, and the conventional EOF is > useless, and should not be set. > My proposed fix is to avoid setting __FLAG_EOF for stream associated with > FIFO after sender was closed. Good findings, and good call. It's worth noting that the Linux kernel exhibits the same behaviour with FIFOs: - EOF will be sent when the last writer closes - subsequent read()s by the same reader will always return EOF - that includes select() and poll(): after the last writer closes, select() and poll() will always return readability/EOF on the reading end of a FIFO, until the reader closes and opens it again. Some other operating systems behave the same way; others don't. The standard does not specify what is right; it allows a lot of implementation-defined behaviour with FIFOs. The generally accepted, portable way to handle sequential reads on a FIFO is for the reader to also open the writing end of the FIFO (and do nothing with it) for as long as it wants to read. The reader is then certain to never get EOF, which only happens when the last writer closes. FIFOs are tricky beasts. They should be used with extreme caution by programmers; leaving low-level FIFO handling to stdio is a good way to shoot yourself in the foot. Which does not mean that stdio should not try to do the right thing, of course. I just have no idea what the right thing is, because different situations call for different answers, and some cases will require EOF while others won't. I suspect that glibc does unholy magic inside stdio for your test case to work with glibc despite the Linux behaviour. And unfortunately, I'm not sure it's avoidable. -- Laurent _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
