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

[Ken Brown <kbrown@cornell.edu>]

On 9/2/2021 3:00 PM, Corinna Vinschen wrote:
> On Sep  2 09:01, Ken Brown wrote:
>> On 9/2/2021 4:17 AM, Corinna Vinschen wrote:
>>> What if the readers never request more than, say, 50 or even 25% of the
>>> available buffer space?  Our buffer is 64K and there's no guarantee that
>>> any read > PIPE_BUF (== 4K) is atomic anyway.  This can work without
>>> having to check the other side of the pipe.  Something like this,
>>> ignoring border cases:
>>>
>>> pipe::create()
>>> {
>>>      [...]
>>>      mutex = CreateMutex();
>>> }
>>>
>>> pipe::raw_read(char *buf, size_t num_requested)
>>> {
>>>     if (blocking)
>>>       {
>>>         WFSO(mutex);
>>>         NtQueryInformationFile(FilePipeLocalInformation);
>>>         if (!fpli.ReadDataAvailable
>>> 	  && num_requested > fpli.InboundQuota / 4)
>>> 	num_requested = fpli.InboundQuota / 4;
>>>         NtReadFile(pipe, buf, num_requested);
>>>         ReleaseMutex(mutex);
>>>       }
>>> }
>>>
>>> It's not entirely foolproof, but it should fix 99% of the cases.
>>
>> I like it!
>>
>> Do you think there's anything we can or should do to avoid a deadlock in the
>> rare cases where this fails?  The only thing I can think of immediately is
>> to always impose a timeout if select is called with infinite timeout on the
>> write side of a pipe, after which we report that the pipe is write ready.
>> After all, we've lived since 2008 with a bug that caused select to *always*
>> report write ready.
> 
> Indeed.  Hmm.  What timeout are you thinking of?  Seconds?  Minutes?

Probably seconds (maybe 20, like the connect timeout for sockets?), but it's 
hard to know without seeing naturally occurring cases where this happens.

>> Alternatively, we could just wait and see if there's an actual use case in
>> which someone encounters a deadlock.
> 
> Or that.  Fixing up select isn't too hard in that case, I guess.

I think this would be my preference, at least during testing (if we can persuade 
people to test it).

Ken