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

[Takashi Yano]

On Tue, 31 Aug 2021 17:50:14 +0200
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.
> 
> So for the time being I suggest the below patch on top of topic/pipe.
> It contains everything we discussed so far.

One more thing. 'git log' cannot stop normally with 'q' with your patch.

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

Byte pipe seems to work for me too.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>