On 9/19/2022 6:05 PM, Enrico Forestieri wrote:
Ken Brown wrote:
> 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.
Please, note that this code was working on cygwin the way it works on linux
until some
time ago, maybe last year, I am not sure. I also found this stackoverflow
discussion:
https://stackoverflow.com/questions/28851639/select-with-non-blocking-reads
I tried the code also on Solaris and NetBSD and it works exactly as on linux, so
I think
it is portable.
Then I guess I'm wrong. I'm really puzzled, because it seems that none of these
platforms agree with POSIX, which says the following in its 'read' documentation:
When attempting to read from an empty pipe or FIFO:
If no process has the pipe open for writing, read() shall return 0 to
indicate end-of-file.
It seems that there's an exception: If no process has ever had the FIFO open for
writing since it was opened for reading, then the FIFO is not considered to be
at end-of-file.
I'll look into fixing this. But I'd be more confident about it if I could find
some documentation of the existing behavior.
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
