X-Recipient: archive-cygwin AT delorie DOT com
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DBA103858422
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=lyx.org
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=lyx.org
Date: Tue, 20 Sep 2022 08:54:37 +0200
From: Enrico Forestieri <forenr AT lyx DOT org>
To: cygwin AT cygwin DOT com
Subject: Re: FIFO issues
Message-ID: <YyljrduQ+ljG6OOa@GIOVE>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <a3084ca6-ea7b-535c-c0fb-2c29e20b7ddb AT cornell DOT edu>
 <1b28b650-b588-e34f-919e-e75f5a01196f AT lyx DOT org>
 <9e531437-9e27-969f-517e-ec5607212c76 AT cornell DOT edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9e531437-9e27-969f-517e-ec5607212c76@cornell.edu>
X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_NONE,
 TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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

-- 
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