public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Norton Allen <allen@huarp.harvard.edu>
To: cygwin@cygwin.com
Subject: Re: FIFO issues
Date: Mon, 19 Sep 2022 15:53:11 -0400	[thread overview]
Message-ID: <6a85ccdf-8e35-241b-ea63-bf9b5f4c85b8@huarp.harvard.edu> (raw)
In-Reply-To: <5d69ee45-a393-bd54-2d7b-2d59117089f6@huarp.harvard.edu>

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.



  reply	other threads:[~2022-09-19 19:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-18 21:45 Enrico Forestieri
2022-09-19 19:15 ` Ken Brown
2022-09-19 19:50   ` Norton Allen
2022-09-19 19:53     ` Norton Allen [this message]
2022-09-19 21:25       ` Ken Brown
2022-09-19 21:28         ` Norton Allen
2022-09-19 22:05         ` Enrico Forestieri
2022-09-19 23:54           ` Ken Brown
2022-09-20  3:51             ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2022-09-20  6:54             ` Enrico Forestieri
2022-09-20 13:18               ` Ken Brown
2022-09-20 17:20                 ` Enrico Forestieri
2022-09-23 15:36                   ` Ken Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a85ccdf-8e35-241b-ea63-bf9b5f4c85b8@huarp.harvard.edu \
    --to=allen@huarp.harvard.edu \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).