Re: [Caml-list] Two questions about using the CamlIDL

[Xavier Leroy <xavier.leroy@inria.fr>]

> Our Caml application is unusual in that the Caml
> app calls C functions, which in turn may call
> Caml functions that return Caml objects to C, 
> which in turn return those Caml objects back to the 
> Caml app.  
> 
> 1. It is not clear how to use the CamlIDL type syntax 
> to define the type of a Caml value that will be returned from C.

Here is a simplistic solution:

  quote(c, "#include "camlobj.h")

  typedef [mltype(string), c2ml(long_to_camlobj), ml2c(camlobj_to_long)]
    long camlobj;

  camlobj f(camlobj v);

where camlobj.h contains:

  typedef long camlobj;
  #define long_to_camlobj(c) (*(c))
  #define camlobj_to_long(v,c) (*(c) = (v))

Basically, a "camlobj" is a long integer whose coercions to and from
the Caml "value" type are the identity function.  

You didn't say what Caml type the Caml objects should have.  I put
"string" here, but any closed type will do.  

The problem with this solution is that the Caml values that transit
through the C code under the type "camlobj" are not known to the GC.
Hence, if a GC occurs (e.g. because your C functions call several Caml
functions in turn), the "camlobj" values will become wrong.

A way to avoid this is to wrap the Caml values in a malloced block that
is registered with the Caml GC:

  quote(c, "#include <camlobj.h>)

  typedef [mltype(string), c2ml(unpack_camlobj), ml2c(pack_camlobj)]
    struct packed_camlobj * camlobj;

  camlobj f(camlobj v);

where camlobj.h is

  typedef struct packed_camlobj { value v; } * camlobj;
  extern void pack_camlobj(value v, camlobj * c);
  extern value unpack_camlobj(camlobj * c);

and camlobj.c contains

  void pack_camlobj(value v, camlobj * c)
  {
    camlobj p = malloc(sizeof(struct packed_camlobj));
    p->v = v;
    register_global_root(&(p->v));
    *c = p;
  }

  value unpack_camlobj(camlobj * c)
  {
    camlobj p = *c;
    value v = p->v;
    remove_global_root(&(p->v));
    free(p);
    return v;
  }

Notice that unpack_camlobj removes the GC root and destroys the
block allocated by malloc().  This is adequate (I hope :-) if your C
code never stores a camlobj in a global data structure, but simply
passes them around.  In more complex situations, you'd need to add a
reference count to the struct packed_camlobj and make sure that the C
code maintains this refcount properly.

> 2. Assuming we can specify the above type, the c_function 
> that calls back into Caml will look something like this:
> 
>   CamlObj c_function() { 
>     CAMLparam0();
>     CAMLlocal2(caml_obj, args);
> 
>     ... Usual set up to get pointer to Caml function 
>     and allocate space for args ...
>     
>     caml_obj = callbackN(*caml_function_closure, 0, args)
> 
>     CAMLreturn(caml_obj);
>   }
> 
> Because c_function will be called from the IDL stub functions,
> do we have to modify the stub functions to follow the same
> function-call protocol as above?

I'm not sure I completely understand your question.  If you're asking
about GC registration of memory roots, I think the "packed_camlobj"
approach above addresses the issue in a way that does not need
modifying the stub functions nor the intermediate C functions themselves.

One last word: in cases of complex C/Caml interactions, as in your
example, it's often easier to work out the (GC) issues first by
writing by hand the stubs for a few functions.  Using CamlIDL from the
beginning makes things even more obscure :-)

Hope this helps,

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners