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

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Sep 7 18:26:51 GMT 2021


On Sep  7 12:14, Ken Brown wrote:
> On 9/6/2021 8:49 AM, Corinna Vinschen wrote:
> > - I think setting chunk to DEFAULT_PIPEBUFSIZE - 1 in the read case and
> >    DEFAULT_PIPEBUFSIZE in the write case by default is dangerous.
> >    Assuming the pipe has been created by a non-Cygwin process, the values
> >    may be way too high.
> > 
> >    Suggestion: Actually set max_atomic_write to something useful.
> >    Set max_atomic_write to DEFAULT_PIPEBUFSIZE in fhandler_pipe::create.
> >    In case of stdio handles inherited from non-Cygwin processes, fetch
> >    the pipe buffer size via NtQueryInformationFile in
> >    dtable::init_std_file_from_handle().  Better, in a matching
> >    fhandler_pipe method called from init_std_file_from_handle().
> 
> How about something like the attached (untested)?

LGTM.  I like the name change!

> > - What about calling select for writing on pipes read by non-Cygwin
> >    processes?  In that case, we still can't rely on WriteQuotaAvailable,
> >    just as before.
> > 
> >    I have a vague idea that we might want to count readers in that case,
> >    but I have to think about it some more.
> 
> Even if we count readers, we have no way of knowing whether a pending read
> has reduced WriteQuotaAvailable to 0.  Maybe this is a case where we should
> impose some artificial timeout, after which we report write ready.  Falsely
> reporting write ready in this corner case seems better than risking a
> deadlock.

Yeah, it's an almost hopeless case.  A timeout may be a way out.


Corinna


More information about the Cygwin-developers mailing list