Regid Ichira wrote: > Quoting pipe(7): > > If all file descriptors referring to the write end of a pipe > have been closed, then an attempt to read (2) from the pipe > will see end-of-file ( read (2) will return 0). > > Consider a pipe with 1 reading and 1 writing processes. The > reading process was put to sleep by the scheduler after he has Strictly speaking it is "blocked waiting for I/O". It isn't asleep. This is a different process queue. (Since you are being pedantic about your question but were sloppy about this description I decided to note this since it is a similar level of detail.) > opened the pipe. The writing process currently writes 1 byte to > the pipe. It will close the pipe immediately afterwards. So > there is a pipe containing 1 byte, no writing processes, and 1 > reading process. Okay. > Am I right that: > > 1. In reality, when the the reading process runs and reads the pipe, > it will see the single byte that was written to it, followed by > an end-of-file. Correct. > 2. Strictly following the quote from above, when the reading > process runs and reads the pipe, it should immediately see an > end-of-file. Note that this sentence does not invalidate the previous sentence which says: Data written to the write end of a pipe can be read from the read end of the pipe. That sentence is still in effect. It precedes the sentence under discussion. If data has been written to the pipe then it can be read by processes reading the pipe. Only if no unread data is in the pipe will the sentence under discussion be triggered. The real problem as I read it is the use of "see" in the description. Since there are no eyes involved the use of the word "see" is problematic. Fortunately it is clarified by what it should have said, that read(2) will return zero. The documentation came from a project to create free documentation for the existing Unix interface. This is a case where the interface is fully specified by existing behavior and the documentation needed to be written (again) with a free(dom) license so that it could be distributed with the new systems. The original documentation was written with a non-free license. We had a kernel and a mostly working system but needed documentation to go with it. It is sometimes difficult to fully describe behavior in a way that cannot be misinterpreted. Note that you might wish to browse the current BSD documentation: http://www.freebsd.org/cgi/man.cgi?query=pipe Note that you might wish to browse the GNU glibc documentation on the same topic. One of the following would do it. $ info libc 'Pipes and FIFOs' $ pinfo libc 'Pipes and FIFOs' $ info --vi-keys libc 'Pipes and FIFOs' http://www.gnu.org/software/libc/manual/html_node/index.html#toc_Pipes-and-FIFOs You might also want to refer to any of the excellent books written by W. Richard Stevens on the topic. I prefer the classic UNIX Network Programming chapter 3 section 4 which describes Unix pipe operation in great detail. > Therefore, pipe(7) choice of words is unfortunate. I think a bug > should be filed. Sure. Bob
Attachment:
signature.asc
Description: Digital signature