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

[Corinna Vinschen]

[Guys, is it asked too much to trim your mails to the required context,
 rather than always performing a Full Quote?  Pretty please...]

On Sep 12 17:46, Ken Brown wrote:
> On 9/12/2021 11:10 AM, Ken Brown wrote:
> > On 9/12/2021 7:04 AM, Takashi Yano wrote:
> > > On Sun, 12 Sep 2021 17:48:49 +0900
> > > Takashi Yano wrote:
> > > > Hmm. Then, what about PoC code attached? This returns to Corinna's
> > > > query_hdl, and counts read/write handles to detect closing reader side.
> > > > 
> > > > If the number of read handles is equal to number of write handles,
> > > > only the pairs of write handle and query_hdl are alive. So, read pipe
> > > > supposed to be closed.
> > > > 
> > > > This patch depends another patch I posted a few hours ago.
> > > [...]
> > 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 problem with the corner case is, how to find out?  You could have
arbitrarily complex process trees with the pipe inherited by grand
children, one of which is a non-Cygwin process.  How does a Cygwin
process tree member learn about that fact, if it didn't start the
non-Cygwin process by itself?

Looks like we have three choices:

- Reintroducing query_hdl as in Takashi's patch.

- select timeouts

- always return "pipe writable"

I think we might try Takashi's idea for as start, no?

Didn't we also have a problem with C# in terms of non-blocking pipes?
I wonder if we could just do the following: As soon as we spawn a
non-Cygwin process, just call set_pipe_non_blocking(false) for all
pipes.  Blocking vs. nonblocking mode is a per-handle thingy anyway.

What do you think?


Corinna