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