From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-04.nifty.com (conssluserg-04.nifty.com [210.131.2.83]) by sourceware.org (Postfix) with ESMTPS id B51743858424 for ; Tue, 31 Aug 2021 08:50:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B51743858424 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-04.nifty.com with ESMTP id 17V8o7GK014449 for ; Tue, 31 Aug 2021 17:50:08 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com 17V8o7GK014449 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1630399808; bh=+XYlbH//tF7u1XU/bAHJsVv3lH74X2kQ+Z+4S2omyRg=; h=Date:From:To:Subject:In-Reply-To:References:From; b=lFIybYOzR6lOMtc0jWOvf5xf+gWLk83pMplJ3FwGDel5bcM1/X/i/iiPxH4X6Bd42 3MMFVCzuG2fNXH6otmz+EH7LAWUyV+yQ7w+J3Ggynivt3Ew28lNdFhMFymhlS4zN9t uXRyfppjSqCB0s2GIV1QHgQSapzYZVUmG/m6fMo8B2pKd+2fwV95KwHMfYUkCfBVDN idMwFkLKULODdvXeQ1lClr1f7D1vA2Kwf2kzis6sTqUWPi4LWZytcmE4aVmdVm9n3n MzPhOBeTqYb+5rVGmsBh0VkaXIEJOntdfGTN0DhCW/3AM1dslT7ty6J2vVgo7L40eI hQEDmb/g6b0ww== X-Nifty-SrcIP: [110.4.221.123] Date: Tue, 31 Aug 2021 17:50:21 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-Id: <20210831175021.c1303ca739910a00866f4fda@nifty.ne.jp> In-Reply-To: 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> 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, 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 08:50:36 -0000 On Mon, 30 Aug 2021 15:31:23 +0200 Corinna Vinschen wrote: > 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. Both side. Writer and reader are C# program. However, only even if only reader side is C# program, the problem occurs when the reader starts to read pipe before the writer writes something to the pipe; i.e. something like: (sleep 0.1; echo AAAAAAAA) | ./reader > 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... In the current topic/pipe head, named pipe for pty is configured as PIPE_TYPE_MESSAGE even if CYGWIN=pipe_byte is set. Pty needs message mode for canonical read. -- Takashi Yano