Browse thread
[Caml-list] Two questions about using the CamlIDL
-
Mary Fernandez
-
Xavier Leroy
- Mary Fernandez
-
Xavier Leroy
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Mary Fernandez <mff@r...> |
| Subject: | Re: [Caml-list] Two questions about using the CamlIDL |
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