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:58 +0000, Rob Hoes wrote:
> > > > 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?
> 
> I think we'd then have to rely on libxl to never copy to pointer
> internally, and throw away the original one. I am worried that this
> may happen, because the ao_how value is temporary.

libxl will for certain take a copy of the pointer passed into the
ao_how, because it stashes it for later use.

Either I'm very confused about what you are suggesting or pointers in C
don't work like you seem to think.

AFAICT caml_register_global_root takes a pointer to the value and locks
down the value itself, preventing it from moving. There is no way for it
to do anything else given a pointer and not a pointer to a pointer.

Ian.

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