Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: cygwin-1.5.16-1: FIFOs broken
Date: Mon, 2 May 2005 17:52:09 +0000 (UTC)
Lines: 48
Message-ID:  <loom.20050502T185614-309@post.gmane.org>
References:  <Pine DOT LNX DOT 4 DOT 44 DOT 0505020202360 DOT 24228-100000 AT ares DOT its DOT yale DOT edu> <20050502145804 DOT GB29132 AT trixie DOT casa DOT cgf DOT cx>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes

Christopher Faylor <cgf-no-personal-reply-please <at> cygwin.com> writes:

> 
> On Mon, May 02, 2005 at 02:36:12AM -0400, Lev S Bishop wrote:
> >On linux, both keep waiting for someone to write to the fifo.  On
> >cygwin, when the second cat tries to listen on the fifo, they both
> >exit.  I don't know how fifos are supposed to work, but I'm guessing
> >cygwin gets it wrong here.
> 
> Yes, this is one of the reasons that I can't say "fifos work fine" in
> cygwin.

Why not look at how POSIX defines FIFOs to work.  XBD 3.162 defines a FIFO as a 
special file whose behavior is further specified in open(2), read(2), write(2), 
and lseek(2).

open(2) states that when opening a FIFO, O_RDWR is undefined (you can only 
portably open a FIFO for just reading or just writing, so bash's `echo <>fifo' 
evokes undefined behavior).  Then, if O_NONBLOCK is set, O_RDONLY succeeds but 
O_WRONLY fails unless there is a previously open reader; if clear, O_RDONLY 
blocks until there is a writer and O_WRONLY blocks until there is a reader.

lseek(2) states that seeking on a FIFO fails with ESPIPE.

write(2) states that there are atomicity requirements on writes less than 
PIPE_BUF bytes.  It also states whether the write will succeed, fail with 
EPIPE, or with EAGAIN, based on blocking mode and available space in the pipe 
to the reader.  But in all cases, it will never return 0 (pipes always make 
progress, or in non-blocking mode return an error immediately).

read(2) states that a reader succeeds with 0 for end-of-file when there is no 
writer, fails immediately with EAGAIN if there is a writer but no data 
available in non-blocking mode, or blocks until the writer provides data (or 
the writer closes) in blocking mode.

When using redirections from the shell command line, you are opening the pipe 
in blocking mode.  So it shouldn't matter whether a writing process or a 
reading process is spawned first (the first end blocks until the second end has 
opened its descriptor), but neither process should complete until the last 
writing process closes its file descriptor (perhaps by exiting) to give the 
reader(s) an end-of-file indication, or the last reader closes its file 
descriptor to give the writer(s) an EPIPE.  The trick of `echo 999999 >fifo&' 
ensures that there is a writer for a very long time, so that a reader never 
gets EOF.

--
Eric Blake



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/