Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Two questions about using the CamlIDL
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-07-17 (20:27)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] Two questions about using the CamlIDL
> 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;
    *c = p;

  value unpack_camlobj(camlobj * c)
    camlobj p = *c;
    value v = p->v;
    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 Archives:
Bug reports: FAQ:
Beginner's list: