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

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Aug 30 09:36, Ken Brown wrote:
> On 8/29/2021 10:15 PM, Ken Brown via Cygwin wrote:
> > On 8/29/2021 8:22 PM, Takashi Yano via Cygwin wrote:
> > > [...]
> > > Even without this problem, select() for writing pipe has a bug
> > > and does not wrok as expected. The following patch seems to be
> > > needed.
> > > 
> > > diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
> > > index 83e1c00e0..ac2fd227e 100644
> > > --- a/winsup/cygwin/select.cc
> > > +++ b/winsup/cygwin/select.cc
> > > @@ -612,7 +612,6 @@ pipe_data_available (int fd, fhandler_base *fh,
> > > HANDLE h, bool writing)
> > >             that.  This means that a pipe could still block since you could
> > >             be trying to write more to the pipe than is available in the
> > >             buffer but that is the hazard of select().  */
> > > -      fpli.WriteQuotaAvailable = fpli.OutboundQuota - fpli.ReadDataAvailable;
> > >         if (fpli.WriteQuotaAvailable > 0)
> > >          {
> > >            paranoid_printf ("fd %d, %s, write: size %u, avail %u", fd,
> > > 
> > 
> > I agree.
> 
> Now I'm starting to wonder.  The use of fpli.OutboundQuota -
> fpli.ReadDataAvailable instead of fpli.WriteQuotaAvailable was introduced in
> commit a010e6abe, with no comment in the commit message or the code to
> explain why.  Corinna, does this make sense to you?  Is it related to the
> issues raised in the message
> 
>  https://cygwin.com/pipermail/cygwin-patches/2004q4/005002.html
> 
> that you cited elsewhere in this thread?

I thought so, but no.  This patch was introduced by cgf in 2008,
and I don't see any hint as to the why in any of my mail archives,
not even in private email.  The only vague hint is the release message
later on:

  - Reworked pipe handling for better speed and better support for signal
    processing.

I wonder if that was a typo, considering the observation from the above
mail:

  "But there is a strange twist:  When a read is pending on an empty
   pipe, then WriteQuotaAvailable is also decremented!"

> BTW, when I was working on the pipe approach to AF_UNIX sockets
> (topic/af_unix branch), I had occasion to step through
> select.cc:pipe_data_available in gdb, and the use of fpli.OutboundQuota -
> fpli.ReadDataAvailable definitely seemed wrong to me.  So when I wrote
> peek_socket_unix on that branch, I used fpli.WriteQuotaAvailable, as Takashi
> is suggesting now.

If that's working reliable these days (keeping fingers crossed for W7),
it's ok if we use that.  We may want to check if the above observation
in terms on WriteQuotaAvailable on a pipe with pending read is still an
issue.


Corinna