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

[Rob Hoes <Rob.Hoes@xxxxxxxxxx>]

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

> 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'll try this now.

> The ocaml source has a few examples of using this function, e.g. for
> signals or as part of caml_register_named_value.
> 
> > Actually, there is one case for which the current code does actually
> > seem alright: when using integers. In this case, the âvalueâ is not a
> > pointer, but the integer itself.
> 
> Is your for_callback an integer now? That might be a reasonable short term
> (i.e. for 4.4) way to solve this issue?

I was thinking about that as a fallback indeed, but I'll try out the above 
first.

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