cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Corinna Vinschen]

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