From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.santannapisa.it (mail.sssup.it [193.205.80.98]) by sourceware.org (Postfix) with ESMTP id DBA103858422 for ; Tue, 20 Sep 2022 06:54:41 +0000 (GMT) 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 Received: from sirio.sssup.it ([193.205.83.80] verified) by santannapisa.it (CommuniGate Pro SMTP 6.1.11) with ESMTPS id 177168660 for cygwin@cygwin.com; Tue, 20 Sep 2022 08:54:40 +0200 Received: from jovis.sssup.it (host-87-14-44-85.retail.telecomitalia.it [87.14.44.85]) by sirio.sssup.it (8.14.5+Sun/8.14.5) with SMTP id 28K6sblA012558 for ; Tue, 20 Sep 2022 08:54:37 +0200 (CEST) Received: by jovis.sssup.it (sSMTP sendmail emulation); Tue, 20 Sep 2022 08:54:38 +0200 Date: Tue, 20 Sep 2022 08:54:37 +0200 From: Enrico Forestieri To: cygwin@cygwin.com Subject: Re: FIFO issues Message-ID: Mail-Followup-To: cygwin@cygwin.com References: <1b28b650-b588-e34f-919e-e75f5a01196f@lyx.org> <9e531437-9e27-969f-517e-ec5607212c76@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 List-Id: 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