Gerd Stolpmann wrote:
> Am Dienstag, den 02.08.2011, 18:01 +0100 schrieb David Allsopp:
> > I don't seem to be able to ask Google this in a way which will give me
> > a reasonable answer!
> >
> > In the same process, if you have one thread blocked on a [recv]
> > operation on a socket, under Unix another thread can still write to
> > the socket. Under Windows, however, the call to [send] blocks because
> > there's another thread blocked on a [recv] to the same socket. Are
> > there any options that can be set to change that behaviour or is that
> > just "the way it is" and the application has to be coded using [select]
> instead?
> 
> Really? This does not make sense at all. It's quite normal that one
> direction is blocked, and the other not. Are you sure about your
> observation?

Seems to be, from the attached - important bit is on the last 10 lines - the function readThread is spawned in a thread of its own and then the loop below reads input and sends each line down the socket.

Compiled with:

ocamlfind ocamlopt -o foo -thread -package unix,threads -linkpkg Foo.ml

and then executed as:

./foo www.google.com

I enter:

GET / HTTP/1.0

followed by two new lines... on Linux I get a response from Google, on Windows it hangs after the first line. 3.12.0 (and 3.10.1 on an old machine) all behaving the same way.

David