From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-02.nifty.com (conssluserg-02.nifty.com [210.131.2.81]) by sourceware.org (Postfix) with ESMTPS id BD3E33857407 for ; Mon, 27 Jun 2022 01:50:49 +0000 (GMT) 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 Received: from HP-Z230 (ak044095.dynamic.ppp.asahi-net.or.jp [119.150.44.95]) (authenticated) by conssluserg-02.nifty.com with ESMTP id 25R1o3pA023016; Mon, 27 Jun 2022 10:50:03 +0900 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 To: cygwin@cygwin.com Subject: Re: poll() is buggy for duplicate file descriptors inquired for different events Message-Id: <20220627105005.c515448857521a7c4eec8f7c@nifty.ne.jp> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2022 01:50:53 -0000 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 > #include > #include > > 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@cygwin.com for this issue. -- Takashi Yano