From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) by sourceware.org (Postfix) with ESMTPS id 6D69C3858417 for ; Mon, 30 Aug 2021 13:31:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D69C3858417 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 1M9FX5-1mOnr241Tj-006PpK for ; Mon, 30 Aug 2021 15:31:23 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 60551A80DB8; Mon, 30 Aug 2021 15:31:23 +0200 (CEST) Date: Mon, 30 Aug 2021 15:31:23 +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: <20210828184102.f2206a8a9e5fe5cf24bf5e45@nifty.ne.jp> <20210829180729.48b4e877f773cb3980c5766d@nifty.ne.jp> <20210830091314.f9a2cb71794d0f68cdb5eba7@nifty.ne.jp> <20210830092259.52f7d54fc3fa340738373af4@nifty.ne.jp> <20210830170204.fa91eaf110f310f13b67abc3@nifty.ne.jp> <20210830210423.00df7f37473b0ac1251e880f@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:T9kDtl8MMpJP1UB7tY8aa7qqYoxApyGX5yMNINwLHE7bQIEorxj lrEN+x1CcIDwb0de1yo4jiYPcsTbkWVgMkXpqC52pufYGjR3DhuId3vusaRgcli5kO9epAi bBmd0vUTl3aCnciUmXJnSdYRDQrcwzDMdnWO0kLrw4qorbShqxxLUSPis4dY4ErOLW9eRDe AxRtAXprC0tlSYafInfUw== X-UI-Out-Filterresults: notjunk:1;V03:K0:AQ8mSlUHecM=:ZjLoHAswiqyaLQkw+zpuyJ /XgZYcG7VX5dgNNEEBEbniV4x6mZgTj6+ZjrH3l4b/8i9Ej3KLwJREEfuRXU+5ofKVWSGyFTQ pkHgoGIrqOMP9dgP1/nOp8QUL48VsAWlKBLjJffo2GGrWyrxb94ylzIOyRaivewuGW0vGW2vE BK+nPLg4hIFrulSq8rssrGVfLNQ/YIRE0Z+QRzhVlvGrb8ByBOneC1+7UQsVHzqR1mr7p8/7y /vDnx0T5++JOheZ3bbSmowcn/3IBCUy9DYJlTXUVXGbgcSvAS9JjX4OOHIn7FjFYaRrv3SM5U 80QxuKePbYICVuPdPj1PYQ9R1IbdMvHsfxdQ8fn1tPF/pwL0p4JJ1cJI2kfIQAf6jPDEWR3VM vLU7dhQdqiDwcEsRlmRL7+TziO8hA1T0tI0MF55W5KzC9+HciXbpKtxvCekbhh/v/v0VzI4BL H+1OJxAFPiJb+29zIrdhgDS/TvsABxcU8l0P49A+MA5tRK/A9KMuvselRVOvPX+PGUdNgv/tw QNHJUc0GRERnaNsIY0I7lDsWSr2NUCYAGrQhatYB5TSDZial8Cz6/C5frZJnyFYz+c2Y+eq3H yfrW9EyrcT0NdAWnSdNi9RxC3shwYzFdsc+DZycSJIL+fQ9xUOIg7jQyonoXSvYaCO4sk+ZBc qCd+I9+8op9jSK4kU7xPP9BaHHJ+M7RzBF3Vw0DmrTBc1l84YsH0PAB2Upk/076r/Fp2XzJV0 QOnQIq2LhqC4VxT53CqTuzpCnWzOBQtHJ2gr7JjSQCKQoYuBNA2F3sw1LKk= 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_H3, RCVD_IN_MSPIKE_WL, 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, 30 Aug 2021 13:31:36 -0000 Hi Takashi, On Aug 30 14:55, Corinna Vinschen wrote: > On Aug 30 21:04, Takashi Yano wrote: > > On Mon, 30 Aug 2021 12:20:30 +0200 > > Corinna Vinschen wrote: > > > [Move discussion to cygwin-developers] > > > > > > On Aug 30 17:02, Takashi Yano via Cygwin wrote: > > > > [...] > > > > Is naming the pipe really necessary? > > > > > > It's not, but CreatePipe is doing this anyway. > > > > > > "Anonymous pipes are implemented using a named pipe with a unique name." > > > https://docs.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-createpipe > > > > > > The reason CreateNamedPipe was used in the first place was that > > > FILE_READ_ATTRIBUTES isn't set by CreatePipe for the write side > > > of the pipe, however, it creates full duplex pipe: > > > > > > https://cygwin.com/pipermail/cygwin-patches/2004q3/004912.html > > > > > > Given the fact that CreatePipe is implemented in terms of > > > NtCreateNamedPipeFile anyway, why should the pipe created with > > > NtCreateNamedPipeFile fail where the pipe created with CreatePipe works? > > > > > > The only reason can be some missing flag, I think. Checking > > > fhandler_pipe.cc::nt_create and comparing that with the default flags > > > for files and other devices, it occurs to me that the SYNCHRONIZE stuff > > > is missing. So, Takashi, what if you call NtCreateNamedPipeFile like > > > this in nt_create: > > > > > > status = NtCreateNamedPipeFile (r, access | SYNCHRONIZE, &attr, &io, > > > FILE_SHARE_READ | FILE_SHARE_WRITE, > > > FILE_CREATE, FILE_SYNCHRONOUS_IO_NONALERT, > > > pipe_type, FILE_PIPE_BYTE_STREAM_MODE, > > > 0, 1, psize, psize, &timeout); > > > > > > Does that fix the above problems, too? > > > > Yes it does! Now, if CYGWIN=pipe_byte is also set, the piping issue > > of C# program is gone! I don't quite understand this one. Is that C# example using the write side of the pipe? If it reads from the pipe, this behaiour would be pretty puzzeling, given the read mode is always BYTE. Either way, assuming we switch the write side to BYTE mode only, is the pty code robust enough to work with that? The comment Note that the write side of the pipe is opened as PIPE_TYPE_MESSAGE. This *seems* to more closely mimic Linux pipe behavior and is definitely required for pty handling since fhandler_pty_master writes to the pipe in chunks, terminated by newline when CANON mode is specified. is old, so the problems the message mode was trying to solve for CANON mode may not apply anymore... Corinna