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

[Ken Brown]

On 8/30/2021 9:20 AM, Corinna Vinschen wrote:
> On Aug 30 15:00, Corinna Vinschen wrote:
>> On Aug 30 10:27, Corinna Vinschen wrote:
>>> [Moving discussion to cygwin-developers]
>>>
>>> On Aug 29 11:57, Ken Brown via Cygwin wrote:
>>>> Corinna, do you still see any benefit to switching to PIPE_NOWAIT?  AFAICT,
>>>> it wouldn't decrease the code size at this point, so the only question is
>>>> whether it might improve performance.
>>>
>>> Pipes are already using PIPE_NOWAIT aka FILE_PIPE_COMPLETE_OPERATION
>>> mode, see set_pipe_non_blocking.  The problem is that it's not used for
>>> blocking pipes.  Rather, blocking pipes use overlapped IO.  Overlapped
>>> IO is conceptually upside-down from the POSIX concept of non-blocking.
>>> Also, the information returned in FilePipeLocalInformation is historically
>>> borderline.  For kicks, see
>>> https://cygwin.com/pipermail/cygwin-patches/2004q4/005002.html
>>>
>>> So my suggestion is to try switching to non-blocking Windows pipes
>>> entirely, even for blocking pipes on the user level.  It works nicely
>>> for sockets.
>>
>> On second thought, I'm not so sure how to block on non-blocking pipes
>> on writing.  Assuming a write fails because the buffer is full, we
>> don't have a waitable object to wait on.  Unless the pipe handle is
>> signalled if writing is allowed, but that would be a first in Windows.
>> So in theory this would still require overlapped IO.  Does that still
>> work as desired if the pipe mode is non-blocking?  I don't think I ever
>> tried that...
> 
> That probably doesn't make sense.  If WriteFile returns without writing
> something, what should overlapped io be waiting on?

The approach I've taken on the topic/pipe branch is to stop using overlapped I/O 
and to always keep the blocking mode of the Windows pipe in sync with the 
blocking mode of the fhandler.  This seems to work pretty well so far, although 
problems could certainly show up after further testing.

Ken