This is the mail archive of the
mailing list for the Cygwin project.
Re: rsync over ssh hang issue understood
- From: Darryl Miles <darryl-mailinglists at netbauds dot net>
- To: cygwin at cygwin dot com
- Date: Thu, 29 Jun 2006 04:28:17 +0100
- Subject: Re: rsync over ssh hang issue understood
Sorry to rake this thread from a few months ago.
Corinna Vinschen wrote (on 27 Apr 2006 ) :
<rant> The "rsync hangs" problem is not actually a new one. We had
these reports already ages ago. However, *nobody* so far having that
problem seem to be willing to actually debug this problem and track it
down. Grrr. </rant>
I've just joined the cygwin mailing list to get to the bottom of this,
for many months I have been unable to rsync between CYGWIN machines
Linux<>CGYWIN where linux is client and pulling data down hangs very
quickly after connection and getting the first large file (> 256Kb) to
How do I pull down ssh/rsync/cygwin.dll and build in a way that I can
see the problem ? What debugging tools can I use ? Can I printf() the
I read further up the thread the issue maybe to do with
winsup/cygwin/select.cc trying to provide emulation of select(2) to
applications and that it doesn't know how to ask Win32 kernel if a
NamedPipe is writable (without blocking). I presume the problem is the
application code blocking when it did not expect it. Is it allowed for
the cygwin.dll to create extra threads that are self managing ?
Allowing for the IO to be offloaded to a worker thread, and while a
thread of active for the emulated pipe fd then you revoke writability
indications from select(2) interface. But if no worker thread is busy
working on that fd then you get writability back ?
This allow part of CYGWIN.DLL to be offload the blocked WriteFileEx()
call to a named pipe, so the function can return control to the application.
Would that be theoretically possible ?
You dont need to create a new thread from every IO to a writable named
pipe, you can keep a small number of threads around that will create
themselves as necessary. Once a thread has completed the IO it can hang
around for a short time, staying alive and going back onto an idle
queue, blocking itself until more I/O was needed or a timeout occurs (5
seconds). If a timeout occurs it removes itself from the idle list and
destroys itself. So you dont take the thread creation hit for every I/O.
I have never worked on or with CYGWIN before do maybe my idea of way off
I personally dont care about any performance hit, if it can make
equivalent semantics works. Nearest semantics to specification take
precedence over performance IMHO.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html