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 2C66C3858D39 for ; Mon, 15 Nov 2021 15:12:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C66C3858D39 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 Express5800-S70 (z221123.dynamic.ppp.asahi-net.or.jp [110.4.221.123]) (authenticated) by conssluserg-02.nifty.com with ESMTP id 1AFFBYat009546 for ; Tue, 16 Nov 2021 00:11:34 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 1AFFBYat009546 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1636989094; bh=RCrj47TAc29LqdOEUaEYA3Tfd/OJM86qv6+5M48KAV8=; h=Date:From:To:Subject:In-Reply-To:References:From; b=WpWqHtLiXYsH4s132AyAnVIplvz5PnQDQ36DBxzelHIXloVUJ5w2j/rzAHlEYDFR3 mO/8iy8yEnp8yjB7ngpOg3SePlvEv82IlMLVdI2Ysf+9VFKzQhPX3o7HKvbtYz0DV2 FO/5oi3s938uWdIdF76gCFMU970BrxXsSGKdo9ZiePkGH5HFEV0kY5RVGeOVqHvWrT Ufe0JkojciHGY1IPqZNQUwqUWCRz/PUOI42deWaD7AN//bdSuQrS17Qx2yyOxKa4yN M65fWMKyOotc3YKlAfb3Oy+V7f3DDKUgVA4qQLX7blaM2ihiUcDCrjfOEOw9Pj4CZY fEl0xMQ93fwzg== X-Nifty-SrcIP: [110.4.221.123] Date: Tue, 16 Nov 2021 00:11:37 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygwin 3.3.x: another problem that may be related to pipes Message-Id: <20211116001137.7daf62c9f2815d5a92a56df0@nifty.ne.jp> In-Reply-To: <20211115233601.f0c9717ee00908505534c976@nifty.ne.jp> 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> 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=-11.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 15:12:11 -0000 On Mon, 15 Nov 2021 23:36:01 +0900 Takashi Yano wrote: > On Mon, 15 Nov 2021 08:57:43 -0500 > Ken Brown wrote: > > On 11/15/2021 8:01 AM, Corinna Vinschen wrote: > > > [Redirected to cygwin-developers] > > > > > > On Nov 15 17:18, Takashi Yano via Cygwin wrote: > > >> raw_read()/raw_write() in fhandler_pipe.cc seems to need handling > > >> of STATUS_PENDING in nonblocking mode. > > >> > > >> I also confirmed the following patch fixes the issue. However, I > > >> am not very sure that this is the right thing. > > >> > > >> Corinna, Ken, what do you think? > > > > > > I'm puzzled. non-blocking pipes return STATUS_PENDING? What on earth > > > is that supposed to mean on non-blocking (as opposed to asynchronous) > > > pipes? The problem is that STATUS_PENDING theoretically requires > > > to wait for... something, the pipe handle, perhaps, and then to check > > > io.Status. > > > > I noticed last week when I was debugging the XEmacs problem that NtReadFile > > occasionally returned STATUS_PENDING. I commented on it here: > > > > https://cygwin.com/pipermail/cygwin/2021-November/249827.html > > > > But I promptly forgot about it when that turned out not to be the problem for > > that bug. My thought at the time was that we needed something like this: > > > > diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc > > index 9392a28c1..aaf09829d 100644 > > --- a/winsup/cygwin/fhandler_pipe.cc > > +++ b/winsup/cygwin/fhandler_pipe.cc > > @@ -336,9 +336,10 @@ fhandler_pipe::raw_read (void *ptr, size_t& len) > > break; > > status = NtReadFile (get_handle (), evt, NULL, NULL, &io, ptr, > > len1, NULL, NULL); > > - if (evt && status == STATUS_PENDING) > > + if (status == STATUS_PENDING) > > { > > - waitret = cygwait (evt, INFINITE, cw_cancel | cw_sig); > > + /* Very short-lived in the non-blocking case. */ > > + waitret = cygwait (evt ?: get_handle (), INFINITE, cw_cancel | cw_sig); > > /* If io.Status is STATUS_CANCELLED after CancelIo, IO has actually > > been cancelled and io.Information contains the number of bytes > > processed so far. > > > > Takashi, does that fix the problem? > > 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 > > Note that the problem reported is not in raw_read(), but in raw_write(). > > If you mean applying above patch for raw_write(), it proberbly fixes the > issue as well. > > This is because ... > > If you pass the pipe handle to WFMO, it imediately returns WAIT_OBJECT_0, > so your patch will work almost same with my patch. I might be wrong. Your code certainly waits for something happening. I am not sure why it works... -- Takashi Yano