This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]