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

[Ken Brown]

On 9/13/2021 8:51 AM, Ken Brown wrote:
> On 9/13/2021 4:40 AM, Takashi Yano wrote:
>> On Mon, 13 Sep 2021 08:54:31 +0900
>> Takashi Yano wrote:
>>> On Sun, 12 Sep 2021 17:46:47 -0400
>>> Ken Brown wrote:
>>>> On 9/12/2021 11:10 AM, Ken Brown wrote:
>>>>> I don't see how this solves the problem.  In the case we were worried about
>>>>> where we have a non-Cygwin reader, the writer has no query_hdl, and you're 
>>>>> just
>>>>> always reporting write ready, aren't you?  Or am I missing something?
>>>>
>>>> BTW, we could just decide that always reporting write ready in this corner case
>>>> is acceptable.  But then we could just do that without going back to query_hdl.
>>>
>>> The various combination of cygwin and non-cygwin cases resuts in:
>>>
>>> W P R: current, query_hdl
>>> c c c: OK     , OK
>>> c c n: NG     , OK
>>> c n c: OK     , OK
>>> c n n: NG     , select() always report write ready
>>
>> Sorry, this was not correct. In fact,
>> W P R: current, query_hdl
>> c c c: OK     , OK
>> c c n: NG     , OK
>> c n c: OK     , select() always report write ready
>> c n n: NG     , select() always report write ready
> 
> What if you use query_hdl to fix the ccn case, but also keep the current code in 
> raw_read that serializes the reads and avoids a large blocking read?  Would that 
> avoid breaking the cnc case?

Never mind.  I don't think that makes sense.  The way I see it now, if we have a 
query_hdl, we should use it.  If we don't have a query_hdl, then we know there 
were non-Cygwin processes in the process tree, and then if WriteQuotaAvailable 
== 0, the pipe buffer might actually be empty.  So I don't see any option other 
than reporting write ready, as in your patch.

I do have a couple of small comments about your patch, which I'll send later.

Ken