FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 04-06-2012, 01:11 PM
Regid Ichira
 
Default Reading from the pipe will see end-of-file when all writing descriptors have been closed

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
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.

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.
2. Strictly following the quote from above, when the reading
process runs and reads the pipe, it should immediately see an
end-of-file.

Therefore, pipe(7) choice of words is unfortunate. I think a bug
should be filed.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1333717912.87219.YahooMailClassic@web120705.mail.n e1.yahoo.com">http://lists.debian.org/1333717912.87219.YahooMailClassic@web120705.mail.n e1.yahoo.com
 
Old 04-06-2012, 05:51 PM
Bob Proulx
 
Default Reading from the pipe will see end-of-file when all writing descriptors have been closed

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
 

Thread Tools




All times are GMT. The time now is 05:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org