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

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

On Sep  7 08:39, Takashi Yano wrote:
> On Mon, 6 Sep 2021 18:08:54 +0200
> Corinna Vinschen wrote:
> > On Sep  6 22:16, Takashi Yano wrote:
> > > Current git head seems to have some bug. With and without my patch,
> > > sftp get for large file causes error:
> > > 
> > > [yano@Express5800-S70 ~]$ sftp 192.168.0.133
> > > yano@192.168.0.133's password:
> > > Connected to 192.168.0.133.
> > > sftp> get test.dat
> > > Fetching /home/yano/test.dat to test.dat
> > > test.dat                                       13%   66MB  66.4MB/s   00:06 ETAReceived message too long 1728053256
> > > Ensure the remote shell produces no output for non-interactive sessions.
> > > [yano@Express5800-S70 ~]$ sftp 192.168.0.133
> > > yano@192.168.0.133's password:
> > > Connected to 192.168.0.133.
> > > sftp> get test.dat
> > > Fetching /home/yano/test.dat to test.dat
> > > test.dat                                       22%  111MB 110.6MB/s   00:03 ETAdo_download: parse: incomplete message
> > > [yano@Express5800-S70 ~]$
> > 
> > I bisected this down to commit 296bd3e78b52, but I'm at a loss in
> > terms of the cause of the problem, ATM.
> 
> Thanks for bisecting this.
> 
> I am not sure this is the correct thing, however, found the following
> patch solves the issue.

Thanks for the patch!  It's not correct as such, because it enables
SA_RESTART behaviour unconditionally, but it gave me the right hint.

The underlying problem is that in case of a signal, the CancelIo call
was missing.  The signal was processed, but the IO was still ongoing
and so data was read or written without the application's knowledge.

Actually we can always call CancelIo.  It doesn't break the information
in the IO_STATUS_BLOCK if the IO was already finished.  It just sets
io.Status to STATUS_CANCELLED and io.Information to the number of bytes
processed if it really canceled the ongoing IO.

I pushed a matching patch.


Thanks again!
Corinna