From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-03.nifty.com (conssluserg-03.nifty.com [210.131.2.82]) by sourceware.org (Postfix) with ESMTPS id CAEC43858402 for ; Thu, 11 Nov 2021 11:12:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CAEC43858402 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-03.nifty.com with ESMTP id 1ABBC53H002783 for ; Thu, 11 Nov 2021 20:12:05 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-03.nifty.com 1ABBC53H002783 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1636629125; bh=XpPafzihfRH3zxc3GhkeIHN0CWeyPZVxQLbS1T1few0=; h=Date:From:To:Subject:In-Reply-To:References:From; b=1dV/a0EmsT1Zocawi9a00c5gTCkGmYZHW8U5rnsr7gy/8r7vzMqWYKV5+qQ1NmqFk fBTiwNpqN2GlUgAg3eCcHuvLP7e+1VovFH50y21AF1JoVGaTAoTljcnLApbg7l7mHf d3CO0lGFpV2rnZqFMDqOXoHA1L2or2AiFo8IW2N9RalvR3wcKoDStUglJehgJ1GRs4 uIglJ1+crnNUJ3PnoLeh9Ve8/XLSvqFLv09Ays/T1G+GhhSsydvccjn8wS4rPLkmsM f3UiuapGsLwryc2fi+Xo6fCjvh3f0XuyRMxgpKgDMBP9pAct9EI0YZ5THB+uLrN6sm V6oMIMdeXqPHw== X-Nifty-SrcIP: [110.4.221.123] Date: Thu, 11 Nov 2021 20:12:06 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: 3.3.0: Possible regression in cygwin DLL (Win10); fixed in snapshot Message-Id: <20211111201206.72cd688ce6a0d72d3a4f6c5f@nifty.ne.jp> In-Reply-To: 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> 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=-6.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Thu, 11 Nov 2021 11:12:36 -0000 On Thu, 11 Nov 2021 10:52:33 +0100 Corinna Vinschen wrote: > 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? I have just confirmed that NtQueryInformationFile(FileNameInformation) also hangs. > 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. Thanks for advice. get_query_hdl_per_* is called in the write side, so only knows pipe handle of the write side. We would like to know ProcessId which have pipe handle of the read side. Can we use FileProcessIdsUsingFileInformation for this perpose? -- Takashi Yano