Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 09 May 1998 00:32:17 +1000
From:      Stephen McKay <syssgm@dtir.qld.gov.au>
To:        "Andreas Huber" <ahuber@ping.at>
Cc:        "Justin C. Walker" <justin@lilith.apple.com>, freebsd-hackers@FreeBSD.ORG, syssgm@dtir.qld.gov.au
Subject:   Re: Question about pipe() 
Message-ID:  <199805081432.AAA03472@troll.dtir.qld.gov.au>
In-Reply-To: <199805080437.VAA01526@lilith.apple.com> from "Justin C. Walker" at "08 May 1998 15:37:53 %2B1000"
References:  <199805080437.VAA01526@lilith.apple.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 8th May 1998, "Justin C. Walker" wrote:

> "Andreas Huber" wrote:
> * I was under the impression that if the write end of a pipe is closed, a
> * read() at the other end of the pipe will return an error (or at least
> * an EOF condition). Apparently it doesn't. Did I miss something? Is
> * there another way to interrupt the read()?

Yes, when the write end is closed, the read end returns 0 bytes to read()
(ie EOF).  You might have duplicated the write end using fork() though and
forgotten to close the copy you don't need.  This is a common mistake.

Similarly, a write when the read end is closed (all copies, remember) will
generate SIGPIPE (which you can set to be ignored) and returns an error
(with errno == EPIPE).

Named pipes are very similar, but I don't think you were talking about these.

>	In case no one's answered: a pipe reader will hang around
>waiting for data to read, the idea being that the pipe reader is a
>"service provider", while the pipe writer is the "service requester".
>A pipe doesn't really have an end-of-file - it's "infinitely long".

I have no idea what this fellow means here.  I suggest you disregard it.

Stephen.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805081432.AAA03472>