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

[Corinna Vinschen]

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?

> 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.


Corinna