Wayne Davison wrote: > I'd imagine that both ssh and rsync start using a lot of CPU because > the socketpair must be indicating that it is ready for a write (or > read) but the actual write() (or read()) fails to return any bytes (as > long as errno is something like EAGAIN, EINTR, or EWOULDBLOCK, rsync > will try again). � If you want to test that theory, you could add some > prints to rsync's io.c file near the 3 uses of EWOULDBLOCK and have it > output what errno it gets. � If you get that fixed, the programs that > interface with a socketpair should go back to normal.
It would not be the first time Cygwin did something like that. 11.5 years ago, Cygwin32 b19.1, I found it returning EAGAIN continuously when reading from pipes to a child process and from the master side of a pty to a child process, while select() indicated "ready for exception" (at least from the pty master; I don't remember if it was that or "ready for read" from a pipe). How interesting that sockpair() now looks like having a similar problem. Perhaps the sockpair problem might be related to the getting stuck people occasionally report with rsync + ssh + Cygwin ? I.e. maybe disabling socketpair() will fix the stuck problem too? Maybe the next time someone encounters it, they'll google this thread, try it and let us know how it went, thanks :) -- Jamie -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
