Patch for slow rsync - select(2) bug

Nigel Stephens nigel@mips.com
Fri Jul 4 23:59:00 GMT 2003


After finally getting bored with the poor performance of rsync on
Cygwin I decided to investigate.

Turns out that when using rsh or ssh as the transport, they soak up
99% of the CPU time. This is because they use non-blocking i/o, but
the Cygwin select() function incorrectly returns "ready for read or
write", even when there is no buffer space available, so they get
stuck in a loop calling select and read/write (which immediately
return EWOULDBLOCK).

The following patch fixes this problem by correctly initialising the
socket's "connect state" for rcmd/rexec sockets and socketpairs, and
then maintaining the state correctly across a fork.

Note, that this doesn't fix the other problem where rsync often hangs
at the end of a transfer. I'll look into this further when I have
time.

Nigel
-- 
                         Nigel Stephens         Mailto:nigel@mips.com
    _    _ ____  ___     MIPS Technologies      Phone.: +44 1223 706200
    |\  /|||___)(___     The Fruit Farm         Direct: +44 1223 706207
    | \/ |||    ____)    Ely Road, Chittering   Fax...: +44 1223 706250
     TECHNOLOGIES UK     Cambridge CB5 9PH      Cell..: +44 7976 686470
                         England                http://www.mips.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030704/6ff5343a/attachment.ksh>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


More information about the Cygwin mailing list