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