X-Spam-Check-By: sourceware.org Message-ID: <44A348D1.6070908@netbauds.net> Date: Thu, 29 Jun 2006 04:28:17 +0100 From: Darryl Miles User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.0.4) Gecko/20060614 SeaMonkey/1.0.2 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: rsync over ssh hang issue understood Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Sorry to rake this thread from a few months ago. Corinna Vinschen wrote (on 27 Apr 2006 ) : > 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. 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/