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

[Corinna Vinschen]

On Aug 31 14:54, Ken Brown wrote:
> On 8/31/2021 1:30 PM, Corinna Vinschen wrote:
> > On Aug 31 12:38, Ken Brown wrote:
> > > And here's a really trivial comment about your patch to raw_write: Where you have
> > > 
> > >    len1 = fpli.InboundQuota - fpli.ReadDataAvailable;
> > > 
> > > I think the code would be slightly clearer if you wrote
> > > 
> > >    len1 = fpli.WriteQuotaAvailable;
> > 
> > D'oh!  That was the idea.  Aparently I forgot it in mid-air...
> 
> One more thing.  For a non-blocking write, according to POSIX, "A write
> request for {PIPE_BUF} or fewer bytes shall have the following effect: if
> there is sufficient space available in the pipe, write() shall transfer all
> the data and return the number of bytes requested. Otherwise, write() shall
> transfer no data and return -1 with errno set to [EAGAIN]."
> 
> So I think the condition for breaking from the retry loop has to be changed from
> 
>   evt || !NT_SUCCESS (status) || io.Information > 0
> 
> to
> 
>   evt || !NT_SUCCESS (status) || io.Information > 0 || len <= PIPE_BUF

Hmm.  I wonder if we shouldn't untangle the raw_write code and handle
blocking and non-blocking writes in two different branches of an if.
That should make things much clearer, shouldn't it?

> And I wonder if we've now uncovered a reason for using message mode: If the
> pipe was created in byte mode, might we get a partial write when len <=
> PIPE_BUF?  I see the following under "Pipes" at
> 
>   https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-writefile
> 
> "When writing to a non-blocking, byte-mode pipe handle with insufficient
> buffer space, WriteFile returns TRUE with *lpNumberOfBytesWritten <
> nNumberOfBytesToWrite."

Good point.


Corinna