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 DDDDE3858039 for ; Mon, 13 Sep 2021 09:07:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DDDDE3858039 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 1N1fzM-1n5kmM4Baa-0120G4 for ; Mon, 13 Sep 2021 11:07:43 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 166D0A80D76; Mon, 13 Sep 2021 11:07:42 +0200 (CEST) Date: Mon, 13 Sep 2021 11:07:42 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20210907122631.65452be8d021ec72259431d5@nifty.ne.jp> <20210909124115.555c6be15d675500617d284a@nifty.ne.jp> <20210909170549.506cc3c1f6029d904fece6dd@nifty.ne.jp> <20210909211940.51ef391e27d43f0421962cb8@nifty.ne.jp> <20210909214246.cd1ff1a3062fea27e51ad4ae@nifty.ne.jp> <33386baf-3b2d-d57f-2ad3-1bd328ed7935@cornell.edu> <20210911075734.aaf37697ba7db2ad14d911a3@nifty.ne.jp> <20210911113517.f74fc3ac1971bbf04c7a9bd1@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210911113517.f74fc3ac1971bbf04c7a9bd1@nifty.ne.jp> X-Provags-ID: V03:K1:1j8FlTQFoM4oCHJ2iq96hSKxEPeIpZVMtV+/8OW8LPh/p4W65vD a1HCbwVL0KQhBUZ+adu1Ma2zf2UsNV2yWHLWiBjKR9ZvEuqZwBD4iELS+Eh9+JwVQwxBQ0F MshyamAR1QiNM/KCXPQydg8tinObWacqiDAwabc2wfH/PJQx0gmso6ZapSVyGNT+JnqamJF rkyI2MxxQH85lDXH3lzlQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:dBP1KpoKQcE=:sYcZVtmbBL2ufB1rJIRP15 37y6ddYSA+avRjzCCTZzYmfhXgmTjlLeo7ey1i9D9kLJx8qk+a8KokLuHAtVDH2Ndm32UckPk WULrGr6TvFNqZT4lWCtrC+RtYZgRSEUDbxmJ6wIR9NqfJXpB6ubLO2H6QR2NxovM/sDAN8juN YsjxHhRV4us2wTu07yERvEHlCKQVjuZLQgLpq114Z28GtRLDeMGFBRL1jZ00OblJ2hN5Pj9ji kyUXcsaTk7Oatxhz/aMjdTaY8tcpp8djyDcSEDtg9cQDvdX7Q7bV0vbUbdOvFRN/gvgRA9eGK w2O4M4TqhpLma0FWlk9Zgn30fXfhjcTN2Ooy+KqCT8OahPN3ONd3FauepbpINh1SJrwV/+XFl drbzq4K6QpspjG6u/t/L8XWtqajCmeF5YZ0QjKQm9KcPbXxK3lDevmga1uu1eCxKNHVff2utp km++I1hx0r70ZeKOE91XL9lTbmJW+lj4oQq6AnL1eFxSA83aI0qumYawU2J8JihlJ0vRlZo2g WUUd55GCX9+O8GKg92FSiUnGjRno0KZhENXVl5smv3tL6HxzeVZmhJPVx7lv9FWu8qo79BaIW doCMSIwpq8rYSeLC5rVd+DNuMvUXc4DCDHhE1rJrjHkfcgkKO1jW5AytjupHeIIm5M2E+6YAE wsfVdcCJEqhR1C2WE3fYvVLNvuwzmuefJi2uGa2DS87DQzisjmBvBB+pD47vZZUM31mQfBLsz EUD8nSQwyiShxltYFRm9ia/fPndrIPbntn+qzPIgTohJQ07/WOGooWCgljc= X-Spam-Status: No, score=-99.6 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: Mon, 13 Sep 2021 09:07:46 -0000 On Sep 11 11:35, Takashi Yano wrote: > On Fri, 10 Sep 2021 22:17:21 -0400 > Ken Brown wrote: > > My suggestion is that we impose a timeout in this situation, after which select > > reports write ready. > > Keeping read handle in write pipe (Corinna's query_hdl) causes problem > that write side cannot detect close on read side. > Is it possible to open read handle temporally when pipe_data_available() > is called? 1. You would have to know which process keeps the other side of the pipe. 2. You would have to have the permission to open the other process to duplicate the pipe into your own process 3. You would have to know the HANDLE value of the read side of your pipe in that other process. Point 1 is (kind of) doable using GetNamedPipeClientProcessId or GetNamedPipeServerProcessId. ZIt's not clear how reliable these functions are, given that both pipe sides are created by the same process and then usually inherited by two child processes communicating over that pipe. Point 2 is most of the time the case, especially when talking with native processes. Point 3 requires some sort of IPC. Having said that, I think this is too complicated. Corinna