This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin-1.5.16-1: FIFOs broken

Christopher Faylor <cgf-no-personal-reply-please <at>> 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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]