From: j h woodyatt <jhwoodyatt@mac.com>
To: caml-list@inria.fr
Subject: [Caml-list] Unix.socket_option in ocaml-3.0.2
Date: Wed, 22 Aug 2001 15:45:10 -0700 [thread overview]
Message-ID: <200108222245.PAA05409@smtpout.mac.com> (raw)
everyone--
I noticed that the Unix library module in 3.0.2 has an improved
interface for socket options. I am grateful for the ability to set
options that are not boolean values, but there are other options that
are still out of reach for me. Specifically, the IP_MULTICAST_XXXX
options, which want IP address values.
I know you could just add more setsockopt_foo and getsockopt_foo
functions, but I want to propose an alternative interface. Please
consider something like the following as a possible addition to unix.mli
(and the appropriate implementation in unix.ml):
---- BEGIN EXCERPT
type socket_option_level and socket_option_name
module type SocketOption_sig = sig
type t
val level: socket_option_level
val name: socket_option_name
end
module type SocketOption_t = sig
type t
val set: fd:file_descr -> t -> unit
val get: file_descr -> t
end
module SocketOption(S: SocketOption_sig) : SocketOption_t with type t =
S.t
module SO_DEBUG: SocketOption_t with type t = bool
module SO_BROADCAST: SocketOption_t with type t = bool
module SO_REUSEADDR: SocketOption_t with type t = bool
module SO_KEEPALIVE: SocketOption_t with type t = bool
module SO_DONTROUTE: SocketOption_t with type t = bool
module SO_OOBINLINE: SocketOption_t with type t = bool
module SO_ACCEPTCONN: SocketOption_t with type t = bool
module SO_SNDBUF: SocketOption_t with type t = int
module SO_RCVBUF: SocketOption_t with type t = int
module SO_ERROR: SocketOption_t with type t = int
module SO_TYPE: SocketOption_t with type t = int
module SO_RCVLOWAT: SocketOption_t with type t = int
module SO_SNDLOWAT: SocketOption_t with type t = int
module SO_LINGER: SocketOption_t with type t = int option
module SO_RCVTIMEO: SocketOption_t with type t = float
module SO_SNDTIMEO: SocketOption_t with type t = float
type ip_mreq = inet_addr * inet_addr
module IP_ADD_MEMBERSHIP: SocketOption_t with type t = ip_mreq
module IP_DROP_MEMBERSHIP: SocketOption_t with type t = ip_mreq
module IP_MULTICAST_IF: SocketOption_t with type t = inet_addr
module IP_MULTICAST_TTL: SocketOption_t with type t = int
module IP_MULTICAST_LOOP: SocketOption_t with type t = bool
module TCP_NODELAY: SocketOption_t with type t = bool
----- END EXCERPT
Comments? (I know. Some of these options are more commonly available
than others. I'm specifically interested in calling attention to the
functorial interface I'm proposing.)
I'm curious to know what are the tradeoffs associated with doing it this
way. I can see how the nested modules are fairly easily done, but the
functorial might be harder, but still possible (maybe with more members
in the input signature, I don't know yet).
Any ideas on how space and time performance would be affected?
--
j h woodyatt <jhw@wetware.com>
"You're standing on sacred ground. Many strange and wonderful
things have transpired right where you're standing."
--unattributable
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
next reply other threads:[~2001-08-22 22:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-22 22:45 j h woodyatt [this message]
2001-08-23 7:02 Ohad Rodeh
2001-08-23 17:19 ` j h woodyatt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200108222245.PAA05409@smtpout.mac.com \
--to=jhwoodyatt@mac.com \
--cc=caml-list@inria.fr \
--cc=jhw@wetware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox