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 52C223858C27 for ; Tue, 31 Aug 2021 23:02:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52C223858C27 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 17VN2FLX018335 for ; Wed, 1 Sep 2021 08:02:15 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com 17VN2FLX018335 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1630450935; bh=CthjZVNBtrS7MxyqKfZU6scNvNf1IXubOIWQRHBdYhY=; h=Date:From:To:Subject:In-Reply-To:References:From; b=e2Fi3tgdlLWM1Ea6cWJNO5Iqk75P8QYXVyMKLCZGEGpGIc+GPqFq0VK3TUmJUVxD+ xmdCWCMNWS0sEe1rMHNSR/izVx1YVgyIzvklxO8+/pXZqF8TcSEcjV9lpv5ZLL4LqQ RyNYJi+XP83jvJhOey6on6vP9jsf4L67WzkXVMr8Em6X6jENwCyoSbvw3DXvYPejhT /A3ZYcCSEa/KRh7fFKCHqedUxZSHJN2OEvWPDkfJWGuCCMnrFFAKTJC3coEDOtmw7H 0VtqLwvc3QdtDyEFDkuMPVValZZrZSzFmCWKIrcV9jTJ/doTfofALUNmqC6LHvdJOf Ie1YXF4d8YwEQ== X-Nifty-SrcIP: [110.4.221.123] Date: Wed, 1 Sep 2021 08:02:20 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-Id: <20210901080220.ee4a5bfbea62cc1ae0a9598e@nifty.ne.jp> In-Reply-To: References: <20210831175534.21edae2356d74a0750c686de@nifty.ne.jp> <20210831182500.4c1c67dae13f51ca68964f63@nifty.ne.jp> <20210831204541.2b56702cdcd2fae5e91ba8e2@nifty.ne.jp> <583ca127-02e7-6b3c-3732-6478c0f862e3@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=-4.4 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: Tue, 31 Aug 2021 23:02:52 -0000 On Tue, 31 Aug 2021 17:50:14 +0200 Corinna Vinschen wrote: > On Aug 31 17:27, Corinna Vinschen wrote: > > On Aug 31 17:18, Corinna Vinschen wrote: > > > On Aug 31 08:33, Ken Brown wrote: > > > > On 8/31/2021 7:45 AM, Takashi Yano wrote: > > > > > On Tue, 31 Aug 2021 12:18:57 +0200 > > > > > Corinna Vinschen wrote: > > > > > > Please try the attached patch on top of topic/pipe. > > > > > > > > > > Thanks for the new patch. I have confirmed that above issue > > > > > is fixed and select() for write pipe seems to work as expected. > > > > > > > > > > > > > > > BTW, I found one minor difference between Linux and this pipe > > > > > implementation. > > > > > [...] > > > > > Is this difficult to be fixed? > > > > Two other remarks: > > > > > > > > 1. I think query_hdl needs to be initialized in the fhandler_pipe constructor. > > > > > > No, that's not necessary. The fhandlers are always ccalloc'ed so they > > > are all 0 anyway. > > > > > > > 2. When the read side of the pipe is non-blocking, there can be no pending > > > > reads, so shouldn't we be able to use WriteQuotaAvailable reliably on the > > > > write side? (I can't test this at the moment.) > > > > > > In theory, yes, but is it a safe bet that non-blocking reads won't change > > > WriteQuotaAvailable on the write side, at least for a very short time? > > > The question is, of course, if that really makes much of a difference. > > > > Oh, btw... why do you want to use WriteQuotaAvailable for normal > > pipes, even though the read side information is available anyway? > > > > We can do that for fifos, no problem, but it doesn't make much sense > > to differ between blocking and non-blocking pipes, the code flow is the > > same. > > So for the time being I suggest the below patch on top of topic/pipe. > It contains everything we discussed so far. One more thing. 'git log' cannot stop normally with 'q' with your patch. > One question left is, do we want to switch to FILE_PIPE_BYTE_STREAM_TYPE > entirely for pipes? I don't see that it's still necessary to use > FILE_PIPE_MESSAGE_TYPE for pipes. Everything seems to work normally > with byte-type pipes. Byte pipe seems to work for me too. -- Takashi Yano