From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) by sourceware.org (Postfix) with ESMTPS id 740DB3858D39 for ; Mon, 15 Nov 2021 16:25:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 740DB3858D39 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MplPh-1mLLFh0SU9-00qEWw for ; Mon, 15 Nov 2021 17:25:08 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 3BA1EA80D6A; Mon, 15 Nov 2021 17:25:07 +0100 (CET) Date: Mon, 15 Nov 2021 17:25:07 +0100 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: cygwin 3.3.x: another problem that may be related to pipes Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <115203324.649908.1636923059546.ref@mail.yahoo.com> <115203324.649908.1636923059546@mail.yahoo.com> <20211115171811.844dce9cce2b4d13262d64f2@nifty.ne.jp> <1f94e84c-59de-bf2c-f244-e4672b981987@cornell.edu> <20211115233601.f0c9717ee00908505534c976@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211115233601.f0c9717ee00908505534c976@nifty.ne.jp> X-Provags-ID: V03:K1:1wkZHOrKfu3GrDDuKM1PCxhMMwUEPDX27zMWapWEwQ/Uu3qNvUS dk7c9B4vfCMtiEG5y1apm4rG6QYkZ0mrr+oxqo9GmrLwTRdAe8Rgf6jU443nu2bAfMkpHgn IXDdoajh9RsioDW3ZQnmgTz1LEx90ky8UNXes4QHidF5v4i5deWSPfigXEulujvkZlMNQDJ aZG3dBQdXXbqIVERW1z3w== X-UI-Out-Filterresults: notjunk:1;V03:K0:gBa+kCRYn+o=:YRb9169+jhwgO02KpCZrOT y59mP3u6eN1OPm1S1gRXptgoR8kyO9vPJWbNU6kTfIGGPTAzDz3TmTkdZCv78+XEKdWmrOuAJ DuEVPsvo4/tG+vi5aEs0JWJXWgQRDXgDdUd3+fSvD0C3s4sSCOpng47QCBrmpteqyvyZN50Ej gDky4TxOPe7Obe8oF3/foXfw5+fkVtkZ/fUpb5S4u92Ki4w/EpAjBa1kohHoeXcHTgFl54kic /f7ZtiQ3es5hIrPEXsN7int4dCoFvxSjIcPILdlwkuhOt9VgH9ePnLBkgqWicF8cYPdoviD2Z fiJNSjfTJFXnUboOp44/BbIcvnUaQ8grnZkRkABjq6ci8vltdf7Xr0NyCXkk9NbWQZc2ddlkv KeI03QAKhHjIbosaUH3ioBOUaCiuADNB/71i3AMf9nKJ1oujP2EHqm1FmvKAMz8eOcifBGifB 4QXIDW7HHU6rs8GDGoLAPNR6uD+fNnbFNzFluO8S91QzKZIDBFnhrLQj69lcw+QkTXwBIz/gA 58z3T+WGQ0shXzfAqJwDsxjHr11ndaqISrRPxryVWLnKPQeAjOwMCSKTgciII1YH1AlWffgZA dSSgbjOQED+rvTh8j4Vb998ecrXow0XdsNZCwHLqY8F72HiENkp6BCq7nyGqhdYJKig3Eu67Y XHTvGlt0s8EeaUBj2Qe9lzrca8sPVEE+BFQqd2YJlap0N/WwyByPBxangXsUaaOpZEL5RF+Gi 5JtKK/CPFQWOFsmY X-Spam-Status: No, score=-99.3 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 16:25:10 -0000 On Nov 15 23:36, Takashi Yano wrote: > [...] > IIUC, WaitForMultipleObject() cannot wait for pipe object. > Only the following objects are allowed to be waited. > > Change notification > Console input > Event > Memory resource notification > Mutex > Process > Semaphore > Thread > Waitable timer Pipe handles shouldn't be any different than the above. Please note that you can also wait, for instance, for socket handles, which are not in that list either. It's just that it's tricky and the developer is potentially doing something which *looks* correct, but doesn't what was intended at all. > If you pass the pipe handle to WFMO, it imediately returns WAIT_OBJECT_0, > so your patch will work almost same with my patch. If it returns with WAIT_OBJECT_0, something has certainly happened on the pipe. The problem is that it's not clear what has happened. If push comes to shove, it could be a completed action actually performed by another process. So here's another brain-dead idea: What if we create the event even in the nonblocking case? Considering that the pipe is nonblocking, what *should* happen is this: - NtReadFile return STATUS_PENDING - WFMO/cygwait even with INFINITE timeout should return almost immediately with WAIT_OBJECT_0 - the io.Status contains a valid status including STATUS_PIPE_EMPTY if there's nothing to read *If* that works, the code in blocking and nonblocking is suddenly almost identical. That would be nice, wouldn't it? If only all the interesting cases would be well documented... Corinna