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 78BB53858D28
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
Message-ID:	<5d69ee45-a393-bd54-2d7b-2d59117089f6@huarp.harvard.edu>
Date:	Mon, 19 Sep 2022 15:50:48 -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
To:	Ken Brown <kbrown AT cornell DOT edu>, cygwin AT cygwin DOT com
References:	<YyeRh5ztNpIUyRKj AT GIOVE>
	<140f644c-4c30-9381-3917-d9f18a0de29d AT cornell DOT edu>
From:	Norton Allen <allen AT huarp DOT harvard DOT edu>
In-Reply-To:	<140f644c-4c30-9381-3917-d9f18a0de29d@cornell.edu>
X-Spam-Status:	No, score=-3.5 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
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
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>
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>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 28JJpSop029062

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.



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

- Raw text -