I just translated that OCaml example to C and it works correctly under Windows 
which suggests it's a bug in OCaml... so I'll attach that ML file to a Mantis 
report, instead!

David Allsopp wrote:
> 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



-- 
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

Reply via email to