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 -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Foo.ml
Description: Foo.ml
