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

[Ken Brown]

On 8/31/2021 12:19 PM, Ken Brown wrote:
> 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.

And here's a really trivial comment about your patch to raw_write: Where you have

   len1 = fpli.InboundQuota - fpli.ReadDataAvailable;

I think the code would be slightly clearer if you wrote

   len1 = fpli.WriteQuotaAvailable;

Ken