9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Joel Salomon <chesky@plan9.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] echo -n
Date: Mon, 20 Nov 2006 11:37:51 -0500	[thread overview]
Message-ID: <e7ce9dadd2e8a46dea26d8199b72ff02@plan9.jp> (raw)
In-Reply-To: <ee9e417a0611200446u79131412xeb756d8b812305a9@mail.gmail.com>

> No, [a zero-length write] doesn't close the pipe.  It sends a
> zero-length message, causing the reader to get a zero-length message
> returned from read.  The pipe is still completely usable; the problem
> is that the reader interprets this zero return as EOF, as is the
> convention.
>
> It's too bad that both of these conditions are signaled the same way,
> but the pipe is *not* closed.
>
> There are two options available for dealing with this: change your
> writer not to write empty messages (as you have), or change the reader
> to ignore them.  For the latter, just ignore a return value of 0 and
> read again.  If the pipe is really closed, then after returning 0
> three times, read will start returning -1.

Why is read from a closed pipe not considered an error, though?
	close(fd[0]);
	for(int i=0; i<5; i++){
		n = read(fd[1], buf, 8);
		print("%d: read %ld bytes: %r\n", i, n);
	}
produces:
	0: read 0 bytes:
	1: read 0 bytes:
	2: read 0 bytes:
	3: read -1 bytes: i/o on hungup channel
	4: read -1 bytes: i/o on hungup channel
where I expected errstr to be set on the first read after pipe
closure.  Is there really no way to immediately determine that a
pipe has been closed?  Why would read be so implemented?

--Joel



  parent reply	other threads:[~2006-11-20 16:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-20  8:40 arisawa
2006-11-20  9:45 ` Martin Neubauer
2006-11-20 10:42   ` lucio
2006-11-20 17:35     ` maht
2006-11-20 12:46 ` Russ Cox
2006-11-20 14:41   ` John Stalker
2006-11-20 14:59     ` Dave Lukes
2006-11-20 14:59     ` Axel Belinfante
2006-11-20 15:34       ` ron minnich
2006-11-20 15:43       ` erik quanstrom
2006-11-20 16:37   ` Joel Salomon [this message]
2006-11-20 18:49     ` Russ Cox
2006-11-20 19:16       ` Francisco J Ballesteros
2006-11-20 19:57         ` Joel Salomon
2006-11-20 20:18           ` Federico Benavento
2006-11-20 20:38           ` Russ Cox
2006-11-20 21:00             ` Joel Salomon
2006-11-20 21:05             ` Francisco J Ballesteros
2006-11-20 21:55               ` Russ Cox
2006-11-20 22:11                 ` Francisco J Ballesteros
2006-11-20 22:24                   ` Martin Neubauer
2006-11-20 23:14                   ` Gorka guardiola
2006-11-20 23:22                     ` Francisco J Ballesteros
2006-11-20 23:57                       ` Gorka guardiola
2006-11-21  3:24               ` lucio
2006-11-20 19:32       ` Joel Salomon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e7ce9dadd2e8a46dea26d8199b72ff02@plan9.jp \
    --to=chesky@plan9.jp \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).