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

Takashi Yano takashi.yano@nifty.ne.jp
Mon Aug 30 12:04:23 GMT 2021


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:
> > On Sun, 29 Aug 2021 22:15:29 -0400
> > Ken Brown wrote:
> > > On 8/29/2021 8:22 PM, Takashi Yano via Cygwin wrote:
> > > > We have two easy options:
> > > > 1) Configure the pipe with PIPE_ACCESS_DUPLEX.
> > > > 2) Use nt_create() again and forget C# program issue.
> > > 
> > > I vote for 2), but let's see what Corinna thinks.
> > 
> > BTW. what's wrong if just:
> > 
> > static int
> > nt_create (LPSECURITY_ATTRIBUTES sa_ptr, PHANDLE r, PHANDLE w,
> >                 DWORD psize, int64_t *unique_id)
> > {
> >   if (r && w)
> >     {
> >       static volatile ULONG pipe_unique_id;
> >       LONG id = InterlockedIncrement ((LONG *) &pipe_unique_id);
> >       if (unique_id)
> >         *unique_id = ((int64_t) id << 32 | GetCurrentProcessId ());
> >       if (!CreatePipe (r, w, sa_ptr, psize))
> >         {
> >           *r = *w = NULL;
> >           return GetLastError ();
> >         }
> >     }
> >   return 0;
> > }
> > 
> > ?
> > 
> > In my environment, I cannot find any defects.
> > - No performance degradation.
> > - set_pipe_non_blocking() works for both read and write pipes.
> > - NtQueryInformationFile() in select() works for both r/w pipes.
> > - Piping C# program works.
> > 
> > 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!

In fact, I've already tested adding the SYNCHRONIZE access flag,
but it didn't solve the problem. It seems that the cause was
that FILE_SYNCHRONOUS_IO_NONALERT was missing.

Thank you for figuring out the solution!

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>


More information about the Cygwin-developers mailing list