From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from endymion.arp.harvard.edu (endymion.arp.harvard.edu [140.247.179.71]) by sourceware.org (Postfix) with ESMTPS id 5A8323858D28 for ; Mon, 19 Sep 2022 19:53:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5A8323858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=huarp.harvard.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=huarp.harvard.edu Received: from [10.245.83.64] (unknown [10.245.83.64]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by endymion.arp.harvard.edu (Postfix) with ESMTPSA id 1AA3426008D for ; Mon, 19 Sep 2022 15:53:12 -0400 (EDT) Message-ID: <6a85ccdf-8e35-241b-ea63-bf9b5f4c85b8@huarp.harvard.edu> Date: Mon, 19 Sep 2022 15:53:11 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: FIFO issues Content-Language: en-US From: Norton Allen To: cygwin@cygwin.com References: <140f644c-4c30-9381-3917-d9f18a0de29d@cornell.edu> <5d69ee45-a393-bd54-2d7b-2d59117089f6@huarp.harvard.edu> In-Reply-To: <5d69ee45-a393-bd54-2d7b-2d59117089f6@huarp.harvard.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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.