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/
