From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by sourceware.org (Postfix) with ESMTPS id 83A8D3858432 for ; Thu, 11 Nov 2021 11:33:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 83A8D3858432 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 1Md6hP-1mCcSY3tFT-00aAPG for ; Thu, 11 Nov 2021 12:33:21 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 3D9FBA80D4A; Thu, 11 Nov 2021 12:33:21 +0100 (CET) Date: Thu, 11 Nov 2021 12:33:21 +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: <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> <20211111201206.72cd688ce6a0d72d3a4f6c5f@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211111201206.72cd688ce6a0d72d3a4f6c5f@nifty.ne.jp> X-Provags-ID: V03:K1:wd2UF5E4qVdfsFiJpP/u/qjfbzb2wXoDKEUS77MmDUE6vHgOCuE 2i+WFau5WYB6LTYLad9iOJHtqaZ6qBojct/nioiG8bX2F80URTbwNqv5Fk7cM6/8hAemf0M swwf6CE+3WVn9tamw93qIUn8QjRBj/o/5sRX1X9q8yQH3kseKCQ3FoLnNppGqlLKkGHuVyQ KIjzycG2m7sl23YMfxDFg== X-UI-Out-Filterresults: notjunk:1;V03:K0:YSOW8DW8vwg=:FC5xHZeFSZ3LVhddrvZtLf bn0oLBu7kLGAkfEPs3J3NMOhABPCFlLNuBMF90sv19VqYr2zGIKsZITTiQnpuC3FR21u+oqxn nCHPjqWoFdt64R3MvYDoMfcEN0UdkaPFT3WC59U2q3H8Y4hd+Wkhbgq1WKvZPRFSm2+CdhEmM iJ2Pq+cJgsQMCmVTW5xrZHJk8UrSMn727qd5Ax/lkMi9QXqIixC447m/73/lzyRKnnRTanEHZ Smu5dOE3QvAM+Y5x1P9CvTRnEsJ6kclShex1luQAln088uwLDdzZDupX8f4AqCLZhMbzfEEjn sO7KFhPxcGWdZPS+iPBAbnhrbvGDddxBJqKJPn9QkdGvyaAdqdA4G/6yvLUZ95B6ceY2HFLIY b+gAJ7I4BEUbJ2nyzFXLhRP+6BiDPsJFhRS52sZek21DEICQx2L87acAP4VwePR+JvDz3ExAG JtYG2ml62nU5oXsEsGMhfFr5pel/eNkmIwIMzR/0Zei+BWQoWkTTDd54EBSbbInOAF1viGakB aRlgtUTNQofz4h3yUkommO6ZCOQLxuGcPAfek1bJhlCK6fQZsrZyIFxZNuTFoIUcBHIW76F6A +Awnnb04UkbPeNZZT1GPeE/2EAWNtpq5cqAyfwb7cUt3e/ifVhO3j3+aAbN4DytE86mm5HIfa xI4vnpzfzL9ly+vpQta5FCdK6JSJNKVasS3eXbP4mpwMw9cf0YMIYCWoXDNkDAa2aTUWY08Ss gpt0/D3zsfUOsRsc 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 11:33:25 -0000 On Nov 11 20:12, Takashi Yano wrote: > 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: > > > > > > 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? > > > > > [...] > > 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. Yeah, drat... but expected. > > [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. Corinna