[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 08/28] libxc: ocaml: add simple binding for xentoollog (output only).



On Fri, 2013-04-05 at 15:04 +0100, Rob Hoes wrote:
> > I think we should avoid returning "bare pointers" to the OCaml heap for two
> > reasons:

malloc is the "C" runtime heap, is that the same as the ocaml heap?
(From your description I understand the distinction isn't relevant in
this context, but I'm curious).

> [...]
> 
> I see, thanks for pointing that out.
> 
> > Instead of returning a "bare pointer" I think we should use a "Custom"
> > value. This involves declaring a "struct custom_operations" like this:
> > 
> >    static struct custom_operations foo_custom_operations = {
> >       "foo_custom_operations",
> >       custom_finalize_default,
> >       custom_compare_default,
> >       custom_hash_default,
> >       custom_serialize_default,
> >       custom_deserialize_default
> >    };
> > 
> > And then wrapping and unwrapping "Custom" blocks using something like:
> > 
> >    #define Foo_val(x) (*((struct foo *)Data_custom_val(x)))
> > 
> >    static value
> >    Val_foo (struct foo *x)
> >    {
> >      CAMLparam0 ();
> >      CAMLlocal1 (result);
> >      result = caml_alloc_custom (&foo_custom_operations,
> >                                 sizeof (struct foo*), 0, 1);
> >      Foo_val (result) = x;
> >      CAMLreturn (result);
> >   }
> 
> I'll update all occurrences of this pattern. The same think happens
> for the libxl context as well.

And probably the libxc context too in that set of bindings?

There's also a malloc in stub_xc_domain_get_pfn_list but that is free'd
in the same C function, which I guess is not subject to this issue?

BTW when looking I found the mmap library uses:
        result = caml_alloc(sizeof(struct mmap_interface), Abstract_tag);

Is that valid? If so then it avoids all the custom operations stuff,
although if you want the finalizer callback then this is worthwhile
anyway.

Also in the same bit of the mmap library the mmap(2) result is stored as
a bare pointer inside that "result" from above, is that visible to the
GC and therefore also dangerous?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.