TeaEngineering / libchronicle

Shared-memory interprocess communication from C using OpenHFT's chronicle-queue protocol
Apache License 2.0
14 stars 10 forks source link

Refactoring to support basic polling and OCaml bindings through Ctypes #7

Open rottened23 opened 4 years ago

rottened23 commented 4 years ago

Wanted to leverage this wonderful library to build an interface to help with bindings for OCaml. Right now this justs supports opening a CQ file and polling it and passing each message back to OCaml through a callback. In terms of the support for OCaml all that was really done was to expose the functionality through a plain c-style format rather having it wrapped in the Kdb C objects.

I don't use C that much and especially Makefiles... so a bit of trial and error here. Regarding the makefile definitely broke the *.so building and likely some other things. I wanted the makefile to produce a single libocamlshmipc.so which has all the linking done for a stand alone package to develop against for ocaml.

Sample polling OCaml usage once the libocamlshmipc.so is on the LD_LIBRARY_PATH.

open Ctypes
open Foreign

let cb_t = uint64_t @-> string @-> uint64_t @-> returning void

let open_and_poll' = foreign "OCAMLshmipc_open_and_poll" (string @-> funptr cb_t @-> returning void)

let open_and_poll st cb = 
    let cb' addr str len = cb 
        (Unsigned.UInt64.to_int addr)
        str
        (Unsigned.UInt64.to_int len)
    in
    open_and_poll' st cb'

let () = 
    let dir = Array.get (Sys.get_argv ()) 1 in
    let cb index str len = 
        print_endline (Printf.sprintf "IN OCAML: index:%d len:%d data:%s " index len str
    in
    open_and_poll dir cb
shuckc commented 4 years ago

Hi Jonathan. I like the changes to shmipc.c, allowing whatever library you are building to provide the parser, encoder and appender, plus some equivalent to K (e.g. Python has PyObject, Java JNI has jobject). It first seemed odd for OCaml bindings to use the mock_k.c shims, but it makes sense. I wrote those just so that I could build some command line tools for demonstration and debug without needing the Kdb runtimes. Ideally unless building bindings for KDB your code would not need to use a K object. Let me properly review this and run your sample code myself and I'll try to get this merged.

rottened23 commented 4 years ago

Hi Chris thanks for taking the time to review the PR! The main reason for using the mock_k objects was as it seemed to help me leverage a lot of what was already there. On the OCaml end the API that is exposed is just "plain old c objects" (i.e. char*, int, etc.) so there isn't any real requirement for needing the KDB objects there. Let me know if you run into any issues with the PR!

shuckc commented 1 year ago

Hi @rottened23 Do you have an example of the ocaml side of things, ie. a script and compiler args? I was looking for a simple reader/writer I could run to exercise this, then port over to the current interface.