This is the mail archive of the 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: Problems with non-blocking I/O

> I guess cygwin doesn't get a lot of testing with non-blocking I/O. We're
> having lots of problems. Using version 1.3.14, we find it barely usable
> problematic and unreliable. With versions 1.3.20 and 1.3.21, it's quite
> unusable. The specific problems are, for 1.3.14:
> 1. selecting for writing on a non-blocking TCP socket will _always_ report
> selection, even when a write to that socket would block
> 2. sockets get closed for no apparent reason. This seems particularly
> after any process has been away from its select loop for a tenth of a
> or two (either it's busy elsewhere, or the scheduler doesn't give it the
> processor because other processes are busy). Symptoms are "Connection
> by peer" errors (when the peer process appears to be perfectly happy to
> talking) and sometimes a EBADF error (not preceded by any other error, ie
> socket has simply ceased to exist without warning).
> For 1.3.20 and 1.3.21, we find that non-blocking reads also fail, with the
> select always reporting selection on read, even when it should block, and,
> much worse than the case for 1.3.14, the read does not block but instead
> manufactures random data (presumably copying from some buffer or other).
> I'm working on making simple test cases for this. I have one that
> the first problem, which I shall attach here. I'll persist with making
> cases for the other problems (I need to strip out irrelevant stuff from
> app) and shall post them when I can reproduce the problems easily.
> The attached source files are for a pair of programs, a client and a
> The server accepts connections on port 8888 and copies any data it
> back to the same socket. The client connects to that port on
> It takes two file names as command line args, reads the first file, sends
> to the socket, then writes whatever comes back from the socket to the file
> given as the second arg. Doing a diff on the two files after both programs
> complete is a test that everything worked. The bigger the file, the more
> stringent the test; I've been testing with files in the tens to hundreds
> megabytes range.
> Both programs produce copious output on stdout to tell you what they are
> doing. When run on linux, the programs run very quickly, with no observed
> problems at all. On cygwin 1.3.14, on Windows 2000, you can see that the
> server side in particular spins through select, reporting EWOULDBLOCK all
> time when selected for write. If you pause (eg ctrl-S) the client, you can
> see it even more clearly. The server should (and on linux does) itself
> in that situation, waiting to be able to write to the socket. On cygwin it
> instead keeps going, constantly raising select conditions and constantly
> finding that it would block on the write, doing a busy-wait. A
> single-processor box illustrates the problem best, as with two processors
> busy-wait doesn't look as bad.


I tried your testcase on files ranging from ~50MG to ~1.5GB (and a few 100k
files) and of every `diff' of the original file against the output file were
the same eg., no output from `diff'. Now I have one WAG (perhaps not so WA),
when you say you tried files that are "tens of hundreds of megabytes" do you
mean files larger than ~2GB (more than one ten :-)? If so then that might be
your problem.

Cygwin doesn't yet (there are spanners in the works) support files larger
than 2GB. Now I'm no socket expert (sure, I can do the basic echo server ;-)
so perhaps someone could confirm/deny this?


Elfyn McBratney
elfyn at exposure dot org dot uk

Unsubscribe info:
Bug reporting:

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