Mail Archives: cygwin/2005/05/02/14:11:26
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/
- Raw text -