Re: FIFO issues

[Enrico Forestieri <forenr@lyx.org>]

On Mon, Sep 19, 2022 at 07:54:11PM -0400, Ken Brown wrote:
> 
> 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.

I compared the behavior of read() and select() on 3 different platforms.
My conclusion is that, actually, read() behaves the same on all of them,
whereas cygwin differs in the way select() works.

As regards the example code posted earlier, on all other platforms
select() returns only when the pipe is written by a client or, if a
timeout is set, it returns 0. Instead, on cygwin it always returns 1.

However, opening the input pipe with "O_RDWR | O_NONBLOCK" instead of
"O_RDONLY | O_NONBLOCK" then cygwin behaves as all other platforms!

-- 
Enrico