From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by sourceware.org (Postfix) with ESMTPS id B9DF63858408 for ; Thu, 11 Nov 2021 16:07:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B9DF63858408 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 1MKKdD-1mzpTl1Sal-00LjHM for ; Thu, 11 Nov 2021 17:07:18 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 74F33A80D4A; Thu, 11 Nov 2021 17:07:17 +0100 (CET) Date: Thu, 11 Nov 2021 17:07:17 +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: <20211110173003.88359e8482ffa8b8be326903@nifty.ne.jp> <20211110223049.b61c6cb87fb3e540b4214bcf@nifty.ne.jp> <20211111201206.72cd688ce6a0d72d3a4f6c5f@nifty.ne.jp> <20211111210234.6a43a2ba237cef11ecc7016b@nifty.ne.jp> <20211111222056.c0ed3ac2fec60b6ff0be8085@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211111222056.c0ed3ac2fec60b6ff0be8085@nifty.ne.jp> X-Provags-ID: V03:K1:DBycTsQBI+lhK7okD/BFwJIJSABno0MH42r68fSuxREPjvgE9Lc DLr5ktwm55bXuQjgf2RYI726VAI+qDaqjDzWCjRJSZBUf4xEsu3pZXjXoIAbselalwl/29T a4TRvN7I7mv28/cM/xVlhEFBJ+fNtuDOcqjEvjv1BEztNS/+S8j19/n/vdeez406yZjKYOl +kQCwUxh9XLjjpMPGDjEw== X-UI-Out-Filterresults: notjunk:1;V03:K0:4j+sQxCMbY4=:TfnXBk+m+QowxEf4ySSwyd h3XJSQeIh1qMr5hsKEW0FvNdbwQG9Th8H9dYbUtLz+5wuw2VqbzLTVni73jm9uk2stUfmWA+w sXcIVH1G/6Mtu/8ZVQau41vIyKB9WuvGvfY0Ja3mRisyqYxTl2UPgK1cOdn1OH1ASJGyEwnda MiCesCMfyNOBDG7eKP4PziBwTOsKlzwssr4Fg3/D6ddsurBjh51/q+1VFrAuPkejJMSVMif3O y4PJNdK5W90rqKJ2U4fGFArhawu1mE0zSoiIX30/E0TFYpdlVP1KEy5juIOp0Y4Pag15K/DJ5 FxlaVLX8l/w5ZRT8LMyjacjWtJu0zAoNSqZGXACPrnfDX71G+ZpY0n210botYb3rzzQDSVDVh KNz0nlcaRNkJSC+n2EPWePo+d4aRqMM7qP5VkxIzglK7scr12THHuK8nnEiP528Osy8TqF/C7 tHOxRnXX+xZpHRtuP1ajl650itvHjxksJ9LN49B6xqmY/icLj2lUcheydZQAvrxVOIzOrz+Ld al2YYFNC8BKhOf/xaO3kj/otO3dg5LFx5KgtPdRQQBx0PSZpL/gaPCdxLPNKu0rrv6yMprvJH 0WhDbTOWiF03pWTsk4O0CfL2ou+HTzEvRbDfOa6M0IF3RLExsKVAhSHzSyQn0E7cjNAtj44nB Czhu0aisFZZJneSwAJy5ks5r4EXZK1uVcYZK8eobt14qzocMtlqYPycgGFbp7MCBSuSTcF9uQ DrT0QIRIGWczotGE X-Spam-Status: No, score=-99.1 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, 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 16:07:21 -0000 On Nov 11 22:20, Takashi Yano wrote: > On Thu, 11 Nov 2021 21:02:34 +0900 > Takashi Yano wrote: > > On Thu, 11 Nov 2021 12:33:21 +0100 > > Corinna Vinschen wrote: > > > On Nov 11 20:12, Takashi Yano wrote: > > > > > [FileProcessIdsUsingFileInformation] > > > > > > > > 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? > > > > > > I don't know. I just stumbled over it yesterday and I thought it might > > > be something we could utilize. Supposedly it returns PIDs for processes > > > having that file open, but how this works for pipe read/write sides > > > needs testing. Of course, knowing how Windows functions usually only go > > > half the way, the function will either only return the current side of > > > the pipe, or even an error code :-/ Never mind, it was just an idea. > > > > I have tested the behaviour of FileProcessIdsUsingFileInformation > > just now. We can use it! I will try to use it in get_query_hdl(). > > I have tried to utilize FileProcessIdsUsingFileInformation in > get_query_hdl_per_process() as the patch attached. It works as > expected. > > I also measured the response of select() using these functions. > The first time and second time responses are measured. The second > time should be much faster than the first time because search > result has been cached. > > First time, Second time > 4.620400 [msec], 0.102300 [msec] << get_query_hdl_per_process() > 19.080400 [msec], 0.199000 [msec] << get_query_hdl_per_system() > 14.364300 [msec], 0.156800 [msec] << FileProcessIdsUsingFileInformation > > Unfortunately, FileProcessIdsUsingFileInformation is slower than > current get_query_hdl_per_process(). It takes about 3 times longer > time. *laughing manically* Your previous mail was a nice surprise, but now we're back on earth it seems. On second thought I guess this even makes sense. At Vista times NtQueryInformationProcess(ProcessHandleInformation) didn't exist, so the method to check this is probably along the lines of your get_query_hdl_per_system function, just faster because it's all implemented in a single system call. And it's probably still implemented this way. Oh well. Thanks for testing! Corinna