Re: [Xen-devel] [PATCH v6 08/12] libxl: ocaml: drop the ocaml heap lock before calling into libxl

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-12-02 at 11:48 +0000, Rob Hoes wrote:
> > > Right, I found out some more about this.
> > 
> > TL;DR: There will need to be a refresh of this patch?
> 
> I think we can keep it simple; see below.
> 
> > [...]
> > > Secondly, storing a value (ocaml heap pointer) in C for a while, and
> > > expecting it to still be up-to-date after a while, is wrong. In the
> > > case of the for_callback pointer in libxl, we currently give it the
> > > our ocaml value directly, and therefore may get out-of-date. I think
> > > that one way to fix this, is to store the value in a global C variable
> > > which is registered with the GC using caml_register_global_root, and
> > > use a pointer to _that_ as for_callback. Or we could use some other
> > > C-allocated variables to pass around, and maintain a mapping to the
> > > ocaml values.
> > 
> > Can't you just use caml_register_global_root on the address of your value
> > for_callback? I presume you can call this register/unregister pair many
> > times (for different events etc)?
> 
> I think you need to register a value, not a pointer to a value.

CAMLextern void caml_register_global_root (value *);

It takes a pointer to the value to register. Is there any reason why you
can't pass &for_callback given "value for_callback" in the local
context?

> 
> > Otherwise you need to build some sort of C-side data structure to hold all
> > the various values, which is doable but a bit tedious I imagine.
> 
> I think we can malloc a new "value" (pointer to ocaml heap), make it
> equal to the for_callback value, register this with the GC (so it can
> update this heap pointer when the actual value moves), and give a
> pointer to it to libxl. And then of course deregister and free before
> we give it back to ocaml.

I think this (moving the heap pointer from the GC) would require the
prototype to be "value **" not "value *".

Ian.


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