Re: rsync over ssh hang issue understood

[Darryl Miles <darryl-mailinglists at netbauds dot net>]

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 
after upgrading.


Linux<>CGYWIN where linux is client and pulling data down hangs very 
quickly after connection and getting the first large file (> 256Kb) to 
download.



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 
cygwin.dll ?



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 
the mark.


I personally dont care about any performance hit, if it can make 
equivalent semantics works. Nearest semantics to specification take 
precedence over performance IMHO.


RFC

Darryl


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