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

[Ken Brown]

On 8/31/2021 11:50 AM, Corinna Vinschen wrote:
> On Aug 31 17:27, Corinna Vinschen wrote:
>> On Aug 31 17:18, Corinna Vinschen wrote:
>>> On Aug 31 08:33, Ken Brown wrote:
>>>> On 8/31/2021 7:45 AM, Takashi Yano wrote:
>>>>> On Tue, 31 Aug 2021 12:18:57 +0200
>>>>> Corinna Vinschen wrote:
>>>>>> Please try the attached patch on top of topic/pipe.
>>>>>
>>>>> Thanks for the new patch. I have confirmed that above issue
>>>>> is fixed and select() for write pipe seems to work as expected.
>>>>>
>>>>>
>>>>> BTW, I found one minor difference between Linux and this pipe
>>>>> implementation.
>>>>> [...]
>>>>> Is this difficult to be fixed?
>>>> Two other remarks:
>>>>
>>>> 1. I think query_hdl needs to be initialized in the fhandler_pipe constructor.
>>>
>>> No, that's not necessary.  The fhandlers are always ccalloc'ed so they
>>> are all 0 anyway.
>>>
>>>> 2. When the read side of the pipe is non-blocking, there can be no pending
>>>> reads, so shouldn't we be able to use WriteQuotaAvailable reliably on the
>>>> write side?  (I can't test this at the moment.)
>>>
>>> In theory, yes, but is it a safe bet that non-blocking reads won't change
>>> WriteQuotaAvailable on the write side, at least for a very short time?
>>> The question is, of course, if that really makes much of a difference.
>>
>> Oh, btw... why do you want to use WriteQuotaAvailable for normal
>> pipes, even though the read side information is available anyway?
>>
>> We can do that for fifos, no problem, but it doesn't make much sense
>> to differ between blocking and non-blocking pipes, the code flow is the
>> same.

Agreed.  It was mainly the fifo case that I was concerned about, and your way of 
handling that is much better than what I suggested.  [I also wondered about the 
pty case, but I see you've dealt with that in your latest patch.]

> So for the time being I suggest the below patch on top of topic/pipe.
> It contains everything we discussed so far.
> 
> One question left is, do we want to switch to FILE_PIPE_BYTE_STREAM_TYPE
> entirely for pipes?  I don't see that it's still necessary to use
> FILE_PIPE_MESSAGE_TYPE for pipes.  Everything seems to work normally
> with byte-type pipes.

Since no one remembers why we're defaulting to FILE_PIPE_MESSAGE_TYPE, I agree. 
  If a problem shows up, we can always rethink it.  I suggest that we still 
retain the CYGWIN option, at least for a while, in case someone encounters a 
problem and wants to switch back to message type for testing.

I'm afraid I still haven't had a chance to do any testing of your patch, but I 
expect to be able to do that later today.

Ken