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 BD3E33857407
Authentication-Results:	sourceware.org;
	dmarc=fail (p=none dis=none) header.from=nifty.ne.jp
Authentication-Results:	sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp
DKIM-Filter:	OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 25R1o3pA023016
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp;
	s=dec2015msa; t=1656294604;
	bh=tNZ4lHCx/8x1O6z1fRg/UxMgZSUnWE/QTwfqfglmLAk=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=UCk7D57k+oBLX8R/XBQugiof5w2P08bOpGojlTxfdem4U6p9Ppb5ay5kTuvoeB+/d
	EY52upFYFrrss+yyNMLDdIZV720jUA+PzlR/hS94br1BENb30GrulFYKFDosDqhaNY
	OHQdI3QF7laW+bqOsWOLS+yZlBbL1qEHWq31ZnM6Kw/u+3qIRjIsOIsb+1HAfLerqF
	lNrkpWPGfoV8cocS6H/Nc9SwtiIABAjFZoI/uUOw2gq21/bvowHpp/i8dG2bH0cWDJ
	hKnFHrYpjgGn43dknLdxgM7j48Cp9eTbzChZDQLQ3vIoZ+r+rPfrb7qC5s2cAxusw4
	9o9VcqiDqwOBw==
X-Nifty-SrcIP:	[119.150.44.95]
Date:	Mon, 27 Jun 2022 10:50:05 +0900
From:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
To:	cygwin AT cygwin DOT com
Subject:	Re: poll() is buggy for duplicate file descriptors inquired for
	different events
Message-Id:	<20220627105005.c515448857521a7c4eec8f7c@nifty.ne.jp>
In-Reply-To:	<DM8PR09MB7095D0733CD9A00FC0847434A5B69@DM8PR09MB7095.namprd09.prod.outlook.com>
References:	<DM8PR09MB7095D0733CD9A00FC0847434A5B69 AT DM8PR09MB7095 DOT namprd09 DOT prod DOT outlook DOT com>
X-Mailer:	Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version:	1.0
X-Spam-Status:	No, score=-4.6 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE,
	SPF_HELO_NONE, SPF_PASS, TXREP,
	T_SCC_BODY_TEXT_LINE 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>

On Sun, 26 Jun 2022 17:04:58 +0000
"Lavrentiev, Anton \(NIH/NLM/NCBI\) \[C\] wrote:
> It looks like if a file descriptor is inquired a few times in a poll() call with different events (and for one of those events the file descriptor is "ready"),
> only that occurrence gets reported correctly, and all other occurrences get the returned event just "copied over" (and thus, it may be incompatible with the
> query for that occurrence).
> 
> The following simple test case demonstrates this:
> 
> $ cat poll.c 
> #include <poll.h>
> #include <stdio.h>
> #include <string.h>
> 
> int main()
> {
>     int n;
>     struct pollfd pfd[2];
>     memset(pfd, 0, sizeof(pfd));
> 
>     pfd[0].fd = 1;
>     pfd[0].events = POLLOUT;
>     pfd[1].fd = 1;
>     pfd[1].events = POLLIN;
>     
>     n = poll(pfd, 2, 1000);
>     printf("n = %d\n"
>     "[0].fd = %d\n"
>     "[0].event = %d\n"
>     "[0].revent = %d\n"
>     "[1].fd = %d\n"
>     "[1].event = %d\n"
>     "[1].revent = %d\n",
>     n,
>     pfd[0].fd,
>     pfd[0].events,
>     pfd[0].revents,
>     pfd[1].fd,
>     pfd[1].events,
>     pfd[1].revents);
> 
>     pfd[1].revents = 0;
>     n = poll(&pfd[1], 1, 1000);
>     printf("n = %d\n"
>     "[1].fd = %d\n"
>     "[1].event = %d\n"
>     "[1].revent = %d\n",
>     n,
>     pfd[1].fd,
>     pfd[1].events,
>     pfd[1].revents);
> 
>     return 0;
> }
> 
> $ gcc -Wall -o poll poll.c
> 
> $ ./poll
> n = 2
> [0].fd = 1
> [0].event = 4
> [0].revent = 4
> [1].fd = 1
> [1].event = 1
> [1].revent = 4
> n = 0
> [1].fd = 1
> [1].event = 1
> [1].revent = 0
> 
> Note that "stdout" is inquired about ready-to-write (in [0]) and ready-to-read (in [1]).
> Because it is ready-to-write, poll() returns immediately, but also having the response
> ready-to-write in [1], where only "read"-compatible status (POLLIN, or POLLHUP, or POLLERR,
> or just 0, if nothing of sorts was available) should have been posted -- but *never* POLLOUT!
> 
> Also note that [1] should have never been flagged as "ready", either, so the return code should have been 1, not 2.
> 
> Finally note that if [0] and [1] were swapped so that [0] was inquired for POLLIN, and [1] was inquired for POLLOUT,
> the result would have still been incorrect on Cygwin ([0] returning POLLOUT for POLLIN inquired).
> 
> For the second invocation, when inquired just singly, the response is correct.
> 
> Now compare it with the correct behavior of the same code, all through, on Linux:
> 
> $ ./poll
> n = 1
> [0].fd = 1
> [0].event = 4
> [0].revent = 4
> [1].fd = 1
> [1].event = 1
> [1].revent = 0
> n = 0
> [1].fd = 1
> [1].event = 1
> [1].revent = 0
> 
> P.S. The manual page for poll(2) says:
> 
> The bits returned in revents can include any of those specified in events, or one of the values POLLERR, POLLHUP, or POLLNVAL.
> 
> So returning POLLOUT(4) for POLLIN(1) violates the rule: bit 0 is NOT set in the binary representation of 4.

Thanks for the report.

I will submit a patch to cygwin-patches AT cygwin DOT com for this issue.

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

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