Browse thread
Re: [Caml-list] Re: Select on channels (again)
-
Christoph Bauer
- Robert Roessler
- Robert Roessler
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Robert Roessler <roessler@r...> |
| Subject: | Re: [Caml-list] Re: Select on channels (again) |
Christoph Bauer wrote:
>>> ...
>>> I did this, but on windows with two programs communicating
>> over a pipe
>>> this isn't enough. select on windows and on a pipe doesn't work.
>>> Therefore I wrote a stub for PeekNamedPipe():
>> "Select on windows" certainly does work... and why not use a
>> socket pair, just as one might on a *nix system? That way,
>> it will work on both.
>
> Select doesn't work on window pipes. In retrospect sockects
> would be the better choice. I stumbled in a strange dead lock
> with theses pipes, because under windows the pipe buffer
> is set to 1024 bytes (otherlibs/win32unix/pipe.c) and will then
> block til the reader reads the contents. IMO this
> value (SIZEBUF) should be zero to let the system choose the best
> buffer size. [1]
>
>> And the fact that socketpair has been left out of the Windows
>> version of the Unix module is not an impediment - it is easy
>> to write a useful implementation in OCaml (I can supply one
>> if needed).
>
> Please supply one.
Here is what I use:
open Unix
module U2 = struct
let socketpair af typ proto =
let listener = socket af typ proto in
let listener_addr = ADDR_INET(inet_addr_loopback, 0) in
bind listener listener_addr;
listen listener 1;
let listener_name = getsockname listener in
let connector = socket af typ proto in
connect connector listener_name;
let acceptor_full = accept listener in
close listener;
(* assert ((getsockname connector) = (snd acceptor_full)); *)
(connector, (fst acceptor_full))
end
... and then select this socketpair or the one from the Unix module at
runtime.
Robert Roessler
roessler@rftp.com
http://www.rftp.com