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

[Ken Brown]

On 8/30/2021 9:51 AM, Ken Brown wrote:
> On 8/30/2021 8:55 AM, 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!
>>>
>>> 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!
>>
>> No worries.  The same should apply to the NtCreateFile side of the
>> pipe, btw.
> 
> I'll add my thanks.  I should have checked the default flags that are typically 
> used for other devices when I wrote nt_create.  I'm glad you caught this.
> 
> So I'll reinstate the use of nt_create and then let Takashi recheck everything.

I've done this now.  I'm still not sure I've got all the flags right.  For 
unknown reasons, I've used FILE_SHARE_READ | FILE_SHARE_WRITE in the call to 
NtCreateNamedPipeFile, and no sharing in the call to NtOpenFile.  Should I also 
use FILE_SHARE_READ | FILE_SHARE in NtOpenFile?  Is sharing even relevant in 
this context?

Ken