From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) by sourceware.org (Postfix) with ESMTPS id 85F0C3858400 for ; Wed, 1 Sep 2021 08:03:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 85F0C3858400 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 (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MtwQk-1n93aA2Ae4-00uHLF for ; Wed, 01 Sep 2021 10:03:06 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5A86CA80D4E; Wed, 1 Sep 2021 10:03:05 +0200 (CEST) Date: Wed, 1 Sep 2021 10:03:05 +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: <20210830210423.00df7f37473b0ac1251e880f@nifty.ne.jp> <932300c9-2e09-5ee5-bbb1-3c060d33e3e1@cornell.edu> <474e1343-9cba-6b3c-b952-c92004968d8f@cornell.edu> <20210831175215.def1505083d496e164fe7ca7@nifty.ne.jp> <20210831200517.ad3088c901ac430346824bb3@nifty.ne.jp> <20210901113911.7fac8e3399319f311d691146@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210901113911.7fac8e3399319f311d691146@nifty.ne.jp> X-Provags-ID: V03:K1:u/+jY4f3bI3aae++6+PTKPK6c44kX95LZdzWmN7ZeHEaPdwdqKk DzGY/9PbWQd0e30qT0gme/5c8mPi8IMDMh/wmgd7SfSkQuRkUWjMXH73Hpz5HiQl6hXqsYL Zcr04XaJOa1f9n3a8Z5qiyFMaOWYr5LlS670Z6kt8Q02wobbSnl6wnT+YHeaBlKgqrKHxYw 6VenyopWthbZxBnuMPVKw== X-UI-Out-Filterresults: notjunk:1;V03:K0:LTvhv16puAE=:l3uwlyNOMlx/ps7EtVPM5S b1WJ6lHCxEFRGoo9uh6fXqz9ZQ/4CjEcBTsAAZ57twboGg+sLdu2s5THuetonfqde6xS9dur8 l5poo5LQFqNN5clTLZvTJB0DxlYAdDoXk3HFY/8/XjkxDMwzn9N7ItyM9so2/r+55F7kTGfCB qblggc9cyYjKP73h5/CTBoCmMoVkuCHBg+/EO/tnfqKy/2d/vd2IjAubasBm9fDewO+SyfL5A T6bRi0PtgH8AGn0oqIpSw2pEVrKMk20COU5JNEzpxpU/LXPwkQcIeOIfHGDhxlGyAvZHSdJ1e Pu++JjEqg36mPNtUfUvCJ8QWcmctmzyBSmv7D2+RM6o2SkWEOFN01aQTWQi7EkwmzOf+8BXVK KAk0RxEp3R4IQ9yF5JkynQP3Itky5dwDwY8ZncUiZ0wTJkB6fNntYSshAG1hxB9MNV9GJk675 Iu3uzVHF1S9Rq92Tg72n84FUgDWOrYNgp3OPLLCSSj1kBQt/eP5rd56O2eE4asBUCgNiylzG4 BOY59QMNC+HLeXyExEtOEfgxdKlb+Ryb9V+tEEq3UQkA2/D0eMZAbBRsoGxsVTKSWikFvJ+56 CorsLKM8kf56Ahz2sVyiZlkzVIyCGRnV4+6oO4VmFHmulaRAz4IcVo+Tc6sF7vGsZvyYRt7Yc 3nADpO9xnHtPw8bB4RE8UEL8qwQOoT7SCwIXl08wH0IvmForaUxeOggfu5mqYryK2OS2ZTWzi 7IJm2iBklgvOCwUB+mXsW9mkHR2rNCwR5LTonGreQqWu9qX4QJXfCl6ayiM= X-Spam-Status: No, score=-100.1 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, 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: Wed, 01 Sep 2021 08:03:11 -0000 On Sep 1 11:39, Takashi Yano wrote: > On Tue, 31 Aug 2021 17:20:25 +0200 > Corinna Vinschen wrote: > > On Aug 31 20:05, Takashi Yano wrote: > > > On Tue, 31 Aug 2021 11:04:05 +0200 > > > Corinna Vinschen wrote: > > > > On Aug 31 17:52, Takashi Yano wrote: > > > > > On Mon, 30 Aug 2021 17:19:44 +0200 > > > > > Corinna Vinschen wrote: > > > > > > But, as I just wrote in my previous mail, the FILE_SYNCHRONOUS_IO_NONALERT > > > > > > flag is probably a good thing for C# apps, but not for Cygwin, because it > > > > > > enforces synchronous operation. Sorry about that... > > > > > > > > > > With FILE_SYNCHRONOUS_IO_NONALERT, what kind of problems are you > > > > > specifically concerned about cygwin pipe? > > > > > > > > We're using asynchronous IO to be able to call WFMO and thus to be able > > > > to handle signals and thread cancellation events. Wit hsynchronous IO > > > > this is not possible. > > > > > > Thanks. How can I regenerate above issue? Stopping by Ctrl-C or killing > > > the process by kill seems to work even with FILE_SYNCHRONOUS_IO_NONALERT. > > > > It may depend on the thread you're running this in. But really, just > > call a blocking (SYNCHRONIZE + FILE_SYNCHRONOUS_IO_NONALERT) ReadFile > > in the main thread of a Cygwin app, and you'll see that neither Ctrl-C > > nor kill signalling will get through. > > I confirmed the issue with FILE_SYNCHRONOUS_IO_NONALERT. There's, of course, a workaround. If you start a thread for each synchronous ReadFile/WriteFile, you can cygwait in the caller for the thread, rather than for the event object of the async IO. If a signal or a thread cancellation request arrives, you can then call CancelSynchronousIo on the ReadFile/WriteFile thread and wait for thread termination. I implemented something along these lines in fhandler_disk_file::mand_lock. Maybe something to consider? It would certainly fix the C# issue, but I'm reluctant to do the thread juggle for each read/write. Corinna