On 9/19/2022 3:53 PM, Norton Allen wrote:
On 9/19/2022 3:50 PM, Norton Allen wrote:
On 9/19/2022 3:15 PM, Ken Brown wrote:
On 9/18/2022 5:45 PM, Enrico Forestieri wrote:
Hi,
I think I am experiencing a problem with fifos on cygwin. The attached
C source (fifocomm.c) creates two pipes (/tmp/pipe.{in,out}), expecting
to receive inputs from /tmp/pipe.in and replying to /tmp/pipe.out.
Compiling this source on linux and launching it produces on the terminal
1) Opening pipes
and then the program waits for someone to write to /tmp/pipe.in.
Opening another terminal and launching the fifotest.sh script (also
attached) produces on the first terminal
1) Closing pipes
2) Opening pipes
and the program continues waiting for another input, while the other
terminal shows "You sent: foo"
Instead, on cygwin, after launching the program one gets:
1) Opening pipes
1) Closing pipes
2) Opening pipes
2) Closing pipes
3) Opening pipes
3) Closing pipes
4) Opening pipes
....
....
meaning that the pipes are continually closed and reopened even if
nobody is writing to /tmp/pipe.in.
Seemingly, the problem is the return value of read() on line 55.
As O_NONBLOCK is set, until no data is available for reading,
read() shouldn't block but should return -1 and set errno to EAGAIN.
After a client that opened the pipe for writing, closes it
(and no other client is using the pipe), read() should return 0 and
only at this point the pipes have to be closed and reopened.
However, on cygwin, read() returns 0 also when nobody is writing to the
input pipe causing the above ping pong. As already said, it works as it
should on linux.
I see what's happening, but I don't see why it's a bug, and I don't
understand why the Linux behavior is different.
On Cygwin, the call to 'select' in line 44 returns immediately with nsel ==
1. This seems correct to me, since the man page for 'select' says, "A file
descriptor is ready for reading if a read operation will not block; in
particular, a file descriptor is also ready on end-of-file." In the present
case a read operation will not block for two reasons: first, O_NONBLOCK has
been set; second, we're at EOF because no process has opened /tmp/pipe.in for
writing. Given that we're at EOF, the return value of 0 for the subsequent
'read' is also correct.
On Linux, 'select' does not return immediately but instead waits for someone
to write to the FIFO.
Can someone explain why Linux is right and Cygwin is wrong here? I must be
missing something obvious.
Ken
This is how I'm reading this, but I have not actually looked at or tried the
posted code yet:
We use select() specifically when we are using non-blocking I/O. All the
blocking happens in select() so we can track multiple sockets. If select()
returns when there is no data available, it's not really doing its job, i.e.
waiting for data. There are of course particular cases where something else
(opening, closing) causes select() to return, which is normal and expected,
but just because the reader is non-blocking is not a good reason for select()
to return.
I should also mention that I use cygwin pipes extensively and have not
encountered this behavior, so maybe I am doing things differently.
You're probably not calling select to check for read ready on non-blocking FIFOs
that have no writers.
In the meantime, I just checked what POSIX says about the meaning of "read
ready" in select, and it's more clear than the Linux man page (quoted above)
about the non-blocking aspect: "A descriptor shall be considered ready for
reading when a call to an input function with O_NONBLOCK clear would not block,
whether or not the function would transfer data successfully. (The function
might return data, an end-of-file indication, or an error other than one
indicating that it is blocked, and in each of these cases the descriptor shall
be considered ready for reading.)"
So I think the Linux man page was just imprecise about this, and select should
not indicate read ready just because O_NONBLOCK was set. But what about the EOF
aspect? In the OP's test case, the FIFO was opened for reading and there were
no writers, so again it seems that select should return read ready and a
subsequent read should return 0. But Linux disagrees.
I did an internet search on this issue and found the following, which describes
the situation we're discussing:
https://stackoverflow.com/questions/14594508/fifo-pipe-is-always-readable-in-select
According to that post, select on Linux will wait for a writer the first time
it's called to check read readiness for a FIFO opened for reading with
O_NONBLOCK set. But if the writer then closes the FIFO, subsequent calls to
select will always find the FIFO read ready (and read will return 0). This
behavior is not documented, as far as I can tell, and in fact it contradicts the
existing documentation (both POSIX and Linux). So I don't think someone trying
to write a portable program should rely on it.
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
