Message-ID: <44A4666A.6020108@netbauds.net>
Date: 	Fri, 30 Jun 2006 00:46:50 +0100
From: Darryl Miles <darryl-mailinglists AT netbauds DOT net>
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
References: <44A348D1 DOT 6070908 AT netbauds DOT net>
In-Reply-To: <44A348D1.6070908@netbauds.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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

The problem goes away if the WIN32 side is Win2003.  Its only Win2k 
which I am seeing problems with.


I have looked through the directory of src/winsup/cygwin and there is 
already stuff creating threads within the context of select.cc for 
"mailslot" support.

There is already a wake up mechanism in place inside cygwin_select().

Initially I can drop the idea of an idle list from the design and go 
with a new thread per unwanted blocked IO when the IO is expected to be 
non-blocking by the app.  This is enough to prove the fix.

So I'm thinking I am half way there.


I also think from reading through the WIN32 API that I either get 
blocking IO or overlapped IO, where overlapped is non-blocking with 
async I/O completion signaling.  This mode isn't directly compatible 
with non-blocking of Unix the way I see it as the data is still queued 
into the kernel for IO.  Not next left with the application in the case 
of errno=EAGAIN of unix.

I don't know enough about real life use of the WIN32 API to know if an 
overlapped IO can block as well.  If that is the case then maybe all 
pipe IO has to be done through a writer thread and we use the busyiness 
state of a writer thread to drive set/reset write_ready state for 
select.  We then serialize all write(2) calls on pipes in FIFO order so 
there is a clear defined order, even if the application happens to have 
multiple threads writing.

Maybe someone with more WIN32 knowledge than me would care to comment.


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/