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 CCE063858402 for ; Thu, 11 Nov 2021 09:52:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CCE063858402 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 (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Mgvev-1mDASK2WoH-00hLFl for ; Thu, 11 Nov 2021 10:52:33 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 3C116A80A5B; Thu, 11 Nov 2021 10:52:33 +0100 (CET) Date: Thu, 11 Nov 2021 10:52:33 +0100 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: 3.3.0: Possible regression in cygwin DLL (Win10); fixed in snapshot Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20211105170542.96ce6dd4ca32880ddfddd660@nifty.ne.jp> <20211106044116.698b465a5d8ed6ce2cc75c99@nifty.ne.jp> <2cfa5de7-3b95-9062-4572-f36d304bc916@cornell.edu> <20211106151047.4d8f626bd6ebe9e4d8017f3b@nifty.ne.jp> <20211110173003.88359e8482ffa8b8be326903@nifty.ne.jp> <20211110223049.b61c6cb87fb3e540b4214bcf@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:24TSqj0nv7MlMoMmncwrF/BG5QDDXaX2MWZm9Y/ou7ZBuYkhs74 TIQt90ayLuv7agUYZtoiCKZ6QGk39mEeDgVGhtD6DxmQB2Z9j7RvIkrn/6YOcVxSH4hBTF2 xm5c2GMeIHTgid/rLeizq58lYZvBQyUkTlIHfoN+D2kia5pMUduxMFC9NwwwSn/VMENmAbU KZKGlIpaZllSzBQTls+CQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:i484K1q0fDM=:TuJq07yZFxCC8rTYmlx6Wr ttoDCKajeM3NgAZB8OdCGhzQ5/+/sGN7gZLriHHJk/x6CydAUxLHQlL0yUpVMDOWmee86i9a8 GTHqa/EA4SX8CQPyjTb8mzkN+qoUBnFAVMuLtlCsq6MZeOo/onim5JujMTVDKwKem7n+VHXXA IaeeNmVp+imfZbKQyUnl9OrYqK6CzvAy2Bk3dJquEomC5xzcQlhQAv4kt2KiYGdw/8xfwkaEu jSFrOqbMj9BZfz90uGyivSivRTUtjOTIbGMngbLftoc2BkjnKuMK/u08WXn4wNmZRbol+o0XV tqAQdiAMHQo0/pJHJbJdkCrkSjiPyfQ55sl9NHqpmODwhkDrv5Msi5Yxe8EgQeUe8WgHCbV2D vzJABMpTIqWqn1eKA5s+p3oe4qSBVjlv43dz/3sbkVlQZwPGmV9DYFnmSNY+Jvat54JhNv44U QYoLMNZdRfev7ypqDCKBqrLTeCh11Lxe/5DdveYLHsgdPI4IKi37jXDYYvu5sSO5hKHfSKItN VDHe3ZZT4yWDnhQa5/V82RiZGrseKpLD7o489n0cDCV8jXqpaj6y7FEzvc6IaBw1il0IP3LGu aYhbeQ+PaU/BQaMnZ67DRDhxxC++8fDCwNlUa24dXv7LxmioYG9nSEJujzjx+UVZqM9cRFL/U Jq7gD7l687BOHuSd0A7H+wULLpnpTxTTobMghe3MoGHbmrNi6TQ7VbHJPvZVVoIKCn4Vseg0L L+VRjEVZJ7I7LLCS X-Spam-Status: No, score=-99.4 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: Thu, 11 Nov 2021 09:52:37 -0000 On Nov 10 21:35, Corinna Vinschen wrote: > On Nov 10 22:30, Takashi Yano wrote: > > On Wed, 10 Nov 2021 11:34:25 +0100 > > Corinna Vinschen wrote: > > > On Nov 10 17:30, Takashi Yano wrote: > > > > I tried to implement your idea, however, I noticed that > > > > NtQueryObject(ObjectNameInformation) call in > > > > get_query_hdl_per_process() is blocked while reading the > > > > pipe if FIPE_SYNCHRONOUS_IO_NONALERT is set and pipe is > > > > in blocking mode. > > > > > > > > So I would like to propose alternative implementation with > > > > FILE_SYNCHRONOUS_IO_NONALERT being set. Please have a look > > > > at attached patch. With this patch, pipe itself in read side > > > > is always set to nonblocking mode and simulate the blocking > > > > behaviour in raw_read(). This can eliminate creating thread > > > > for reading as well as calling CancelSynchronousIo(). > > > > > > > > Note that setting FILE_SYNCHRONOUS_IO_NONALERT only for read > > > > pipe seems to be enough for C# programs. > > > > > > > > What do you think of this implementation? > > > > > > Can you push this to the topic/pipe branch for playing? I updated > > > the branch to current master. > > > > Thanks. I have just pushed the experimental patch to topic/pipe. > > Please try. If something wrong, please point it out. > > Great, I'll have a look. Ken, you're looking as well, right? What I like with this approach is that it actually simplifies the code. What I don't like much is that we are now running a busy loop, but the NtQueryObject hang is... disappointing, to say the least. What about using another function like NtQueryInformationFile(FileNameInformation)? I bet this hangs, too, right? Btw., while looking I was wondering if get_query_hdl_per_process and get_query_hdl_per_system could be replaced by a function utilizing NtQueryInformationFile(FileProcessIdsUsingFileInformation). This supposedly returns all process ids of processes having an open handle to this file. This could be quite a bit faster than the other two functions, ideally. Per MSDN, FileProcessIdsUsingFileInformation exists since Vista. Corinna