[Caml-list] Writing to a blocked socket

[Caml-list] Writing to a blocked socket

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


David

[the astute Mr Holmes may have spotted that having got ocaml-ssl built, I
then couldn't get its stelnet example to work ;o)]

Re: [Caml-list] Writing to a blocked socket

[Gerd Stolpmann]

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?

Gerd

> 
> 
> David
> 
> [the astute Mr Holmes may have spotted that having got ocaml-ssl built, I
> then couldn't get its stelnet example to work ;o)]
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.
------------------------------------------------------------

RE: [Caml-list] Writing to a blocked socket

[David Allsopp]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

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

[-- Attachment #2: Foo.ml --]
[-- Type: application/octet-stream, Size: 1723 bytes --]

let host = ref ""
let port = ref 80

let usage = "usage: foo host [-p port]"

let _ =
  Arg.parse
    [
      "-p", Arg.Int (fun i -> port := i), "\tPort";
    ]
    (fun s -> host := s) usage;
  if !host = ""
  then Printf.printf "%s\n\n" usage
  else let sockaddr =
         let host =
           try
             Unix.gethostbyname !host
           with Not_found -> failwith "Host not found"
         in
           Unix.ADDR_INET (host.Unix.h_addr_list.(0), !port)
       in
         let socket =
           let s = Unix.socket Unix.PF_INET Unix.SOCK_STREAM 0
           in
             Unix.connect s sockaddr;
             s
         in
           let bufsize = 1024
           in
             let buf = String.create bufsize
             in
               let loop = ref true
               in
                 Printf.printf "Connection ok.\nType 'exit' to quit.\n\n%!";
                 let readThread () =
                   let buf = String.create bufsize in
                     while !loop
                     do
                       let r = Unix.recv socket buf 0 bufsize []
                       in
                         Printf.printf "%s%!" (String.sub buf 0 r)
                     done
                 in
                   ignore (Thread.create readThread ());
                   while !loop
                   do
                     Printf.printf "Ready> %!";
                     let r = Unix.read Unix.stdin buf 0 bufsize
                     in
                       if r = 4 && String.sub buf 0 4 = "exit"
                       then loop := false
                       else ignore (Unix.send socket buf 0 r [])
                   done

RE: [Caml-list] Writing to a blocked socket

[David Allsopp]

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