X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED3FB3857C7E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1630140287; bh=GhXt6oMq2OVaFmeh4D6udiYcwT+8Qme2mrdjxCRMclg=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=JrDHCB5uAw/5xO57Yva7yuVLtfcXJsdjGW5Kq4omTzllMTGgGuvnwo8nudOLVAvo2 EvBR5S+Hq0Zovs7rgi9IFwbhnrVg9gsbBjhrMEE14vv0XeM9GSM5ufDQrANsk/oIqD TQgXCdQlokULDXGQ5bD25fBNe72rnmF1py91RiIs= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 457BC3858D34 Date: Sat, 28 Aug 2021 10:43:27 +0200 To: cygwin AT cygwin DOT com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-ID: Mail-Followup-To: cygwin AT cygwin DOT com References: <41A583E1-C8E7-42AB-9F24-EEC33A41EC60 AT house DOT org> <20210825201845 DOT 07b6400b79dc5558a7761efe AT nifty DOT ne DOT jp> <20210826062934 DOT 54f2f2216021c095bb7ba13b AT nifty DOT ne DOT jp> <3b560051-ab27-f392-ca4b-d1fd9b5733b0 AT cornell DOT edu> <20210827202440 DOT 47706fc2fc07c5e9a1bc0047 AT nifty DOT ne DOT jp> <4f2cb5f3-ce9c-c617-f65f-841a5eca096e AT cornell DOT edu> <20210828022111 DOT 91ef5b4ff24f6da9fadb489e AT nifty DOT ne DOT jp> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210828022111.91ef5b4ff24f6da9fadb489e@nifty.ne.jp> X-Provags-ID: V03:K1:h7JTt9w34MHzNX1FjOfos2VL/E3/okYO9+yeAt62Pln/KMm4dvX wqutdJqq4tdaXVZZt777YSz4Y1bJH/VSPaIvWm5HrXYQWmya/k/PcCRn2PNH4RBmKw3GEYY FCm0q6pjoBJ6yNiozXdxRlt9wWVq4OTH2FLeBtgeHhHiLFGkjelsWLNGOBJGk0cTlKiQzMN vlHrQwbY4AbQ6iSE+q7XQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:e50E5Bq8BU4=:l+WERFBKXf8/tRcxVxTZzi 2K+kAGhJf0W7/dTcbRyh212fvpMd4ztaxBEF07DNCGleMKHMtdfuMMyLIP8GLC05brsvmRHS2 Rc2HZNCUakxzCzp26hYupgPYU+LITWuDrjYwfzy2FM6JspxnYR8A4cnE/0dqXdLsnipBNwtwo ft3woMi24vA3UNBrYGXYLw1k8baSQRReGymHdsGPgYCDgEloNrLi16psBj9E0aO9+QzR/eFcp NShJwhLRlTTz5MYBb7Y51z/QycRUew2x5tcn/tXkE96JzGlqEFEYQE+eFeeIpT+Pb0cjsrnp4 KrU5FLWJx0omc+Y/HFQGdv5jmh+hPEdDv6+V8dVmCr6tPncee2ISu7w1xm7VPGL2vPnrv282J feV9EC3/uUoYjnAxEpimLmT61d/trZDrgk3CJOQmsZpoOgRxUXkc90RPth2dK02GQyy6XKuRs XsuUK4LCFW0S+QXepqUbLfqdYbeRXPGarplWgzk3KQSYVg5fkevfofmm3DDTNfQkS1lfcMhcy ZqGbwYrmvlptMCyGck7wEO+BdRClLwao0r16LmXd/S8/Sh8w/0LzWhDzz4Ovn4anTwO/auGjP ZADXUCp/GV6J4H/Y6Te7mz/eUYRTfFi22EaWYHH5/PeceRqiR8ALoCXI8neZBK1aj1CetFTvG 9D/Q3XdQWLjnJZBgYcsi+nlZjUg2EGKFR54Vam+usf0FM66yyxnSbjYTdniJ/v0Av+oWcd+aP R/wxBV23/AZ7FdbW6fCKtoVnrkHUk3sgJJj+w7QGjypuGP25qagfapBKcs4= X-Spam-Status: No, score=-100.0 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, 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 AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" On Aug 28 02:21, Takashi Yano via Cygwin wrote: > On Fri, 27 Aug 2021 12:00:50 -0400 > Ken Brown wrote: > > Two years ago I thought I needed nt_create to avoid problems when calling > > set_pipe_non_blocking. Are you saying that's not an issue? Is > > set_pipe_non_blocking unnecessary? Is that the point of your modification to > > raw_read? > > Yes. Instead of making windows read function itself non-blocking, > it is possible to check if the pipe can be read before read using > PeekNamedPipe(). If the pipe cannot be read right now, EAGAIN is > returned. The problem is this: if (PeekNamedPipe()) ReadFile(blocking); is not atomic. I. e., if PeekNamedPipe succeeds, nothing keeps another thread from draining the pipe between the PeekNamedPipe and the ReadFile call. And as soon as ReadFile runs, it hangs indefinitely and we can't stop it via a signal. Is a blocking ReadFile actually faster than a non-blocking read? Or does it mainly depend on BYTE vs. MESSAGE mode? What if the pipe is created non-blocking and stays non-blocking all the time and uses BYTE mode all the time? Just as sockets, it would always only emulate blocking mode. Wouldn't that drop code size a lot and fix most problems? Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple