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

[Mary Fernandez <mff@research.att.com>]

Xavier,
Thanks very much.  That is extremely helpful
and answers all our questions.
Mary
On Thu, 2003-07-17 at 16:27, Xavier Leroy wrote:
> > 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
-- 
Mary Fernandez <mff@research.att.com>
AT&T Labs - Research

-------------------
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