Re: cygwin + rsync issue under Windows 7 x64: follow up

[Eliot Moss <moss at cs dot umass dot edu>]

As I reported yesterday, I had noticed a problem with
latest rsync (3.0.7-1) under latest cygwin on
Windows 7 x64. Sometimes rsync of a large file over
compressed ssh channels goes into a busy wait with
no progress, consuming all the cpu.

Now I have better evidence that points to something
in the cygwin socketpair implementation:

I built rsync 3.0.7 from source locally, and found
that the "out of the box" version, which has use
of socketpair enabled, exhibits the hanging. If
I turn off HAVE_SOCKETPAIR in config.status (by
manually editing that line), then the resulting
rsync works ok.

My guess is that this has something to do with
detecting whether data is available on one of
the sockets. It appears that a chain of processes
gets built with pipes/sockets between them for
rsync, ssh, and zip.

Given that this occurs only sometimes and apparently
only on rsync transfers related to large files (but their
contents may not have changed much) I am at a loss to
come up with a simple test case.

Perhaps the rsync implementers can confirm that the
only coding difference in the presence of HAVE_SOCKETPAIR
is in the construction of communication channels between
processes, and that those file descriptors are otherwise
used in the same way, with or without socketpair. And
perhaps also indicate the style in which rsync uses the
sockets?

In any case, I take the current evidence as leaning more
towards there being a bug in cygwin's socketpair / socket
implementation.

Again, what further information do you want? Corinna,
IIRC, I still have that particular BLODA installed that
you wanted me to have to test about the previous issue
with socketpair, fixed back in November ....

Regards -- Eliot Moss

--
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