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

[Takashi Yano]

On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
> On Sat, 28 Aug 2021 10:43:27 +0200
> Corinna Vinschen wrote:
> > 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.
> 
> Hmm, you are right. Mutex guard seems to be necessary like pty code
> if we go this way.

I have found that set_pipe_non_blocking() succeeds for both read and
write pipes if the write pipe is created by CreateNamedPipe() and the
read pipe is created by CreateFile() contrary to the current create()
code. Therefore, not only nt_create() but also PeekNamedPipe() become
unnecessary.

Please see the revised patch attached.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2-0002-Cygwin-pipe-Revert-to-create-rather-than-nt_creat.patch
Type: application/octet-stream
Size: 8881 bytes
Desc: not available
URL: <https://cygwin.com/pipermail/cygwin/attachments/20210829/52614467/attachment-0001.obj>