[zeromq-dev] Introducing Caravan: Simple, Faithful ZMQ-Bindings for Objective Caml (Pedro Borges)

Pedro Borges pdhb.lists at gmail.com
Mon Apr 4 23:39:08 CEST 2011


On Mon, Apr 4, 2011 at 7:38 PM, Brian Ledger <bpl29 at cornell.edu> wrote:

> You are mistaken on the int64 issue.  The OCaml Int64 API states that
> arithmetic is carried out modulo 2^64, just like an unsigned int, which does
> not have to use a sign bit from it's allocation.  However, the Int64 still
> supports negative integers (probably by an additional sign bit) and so we
> must coerce the Int64 from it's range of [-2^64,2^64]

Int64's range is [-2^63, (-2^63) - 1] so there is no way to set the
affinity for the 64th thread.

> I don't think I quite understand the clause concerning interoperable socket types for our two
> APIs.  Because sockets cannot be passed between threads, the only scenario I can
> foresee in which this would be problematic is if someone was using both of our APIs at the > same time in the same application.

Interoperability in the sense that users could pass the socket created
by your bindings to the utility methods.


I already forked your repo but this week I don't have much time to
improve the bindings. Here is what I'm going to do:

 - wrap your opaque types in custom blocks and write the smart
finalizers (they close and term stuff if it wasn't closed already),
keep in mind however that it's advisable to keep the close and term
functions and their use should be mandatory since dealing with error
at finalization time is weird.
 - implement the poll and the devices
 - see if I can factor some error code
 - try to eliminate some unnecessary closure allocations
 - Write the higher level API on top (things like has_more, subscribe,
unsubscribe, receive_fully and receive_no_block returning an option
type on EAGAIN).
 - I won't add the type parameters to the socket type.

Finally, ocaml-zmq will be dropped.



More information about the zeromq-dev mailing list