From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-01.nifty.com (conssluserg-01.nifty.com [210.131.2.80]) by sourceware.org (Postfix) with ESMTPS id 784C63858D39 for ; Mon, 15 Nov 2021 14:36:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 784C63858D39 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-01.nifty.com with ESMTP id 1AFEZwkL022716 for ; Mon, 15 Nov 2021 23:35:58 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com 1AFEZwkL022716 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1636986958; bh=49d94otnPhcRqBTFFprxzixaNqBhjx+5k3HKsWd4Nuk=; h=Date:From:To:Subject:In-Reply-To:References:From; b=TrmEc1ndVc3gjcedfhwQ4aNc1WxlOkcUoTdobC7Ym5mD7s+jZ7q0qbTlCjOH12ACd NToPj6I0zrqAy6Jc2o3AsvRr9yIQDyf4+CoR0WZDK3hVsQIRQY4GvFl49acZh0asc0 hRfVM1xaHU30srXI4fJe3EGIl6fHK+dvgoyrjUuz4zc1QVcWdaiWinfLYgeF3x9oTH eKvbKWzNpOSGrHelCNQdpvIQsVnNccWpgjmNy0LxOa6VPVoC0/oCB4oYdkzjnEAfC2 gJNrPJTV7dgEoTU9ZjNu1cgG9Iz5dXtmhfj4YvQCU8UdhO8lKT+5wyOvMeT9u/IoRj XrsSZClk1OoWw== X-Nifty-SrcIP: [110.4.221.123] Date: Mon, 15 Nov 2021 23:36:01 +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: <20211115233601.f0c9717ee00908505534c976@nifty.ne.jp> In-Reply-To: <1f94e84c-59de-bf2c-f244-e4672b981987@cornell.edu> 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> 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, RCVD_IN_MSPIKE_H2, 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 14:36:27 -0000 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. -- Takashi Yano