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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-11-29 at 18:33 +0000, Rob Hoes wrote:
> On 29 Nov 2013, at 10:48, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Fri, 2013-11-29 at 09:03 +0000, Rob Hoes wrote:
> >> On 29 Nov 2013, at 08:39, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >>> I wonder if you need to use these functions:
> >>>> /* [caml_register_global_root] registers a global C variable as a memory 
> >>>> root
> >>>>  for the duration of the program, or until [caml_remove_global_root] is
> >>>>  called. */
> >>>> 
> >>>> CAMLextern void caml_register_global_root (value *);
> >>>> 
> >>>> /* [caml_remove_global_root] removes a memory root registered on a 
> >>>> global C
> >>>>  variable with [caml_register_global_root]. */
> >>>> 
> >>>> CAMLextern void caml_remove_global_root (value *);
> >>> 
> >>> To keep the for_callback value live?
> >> 
> >> Perhaps, yes, if a global root is something that is not only never
> >> deallocated, but also never moved. I remember we discussed this topic
> >> when revising v1 of the series, and I ended up with the current
> >> implementation that keeps a reference to the value at the ocaml level.
> >> 
> >> I wonder how ocaml tracks live values when they may move around. Iâll
> >> see what I can find out.
> > 
> > My google-fu wasn't sufficient to answer this, perhaps you have a
> > hotline to someone who knows though ;-)
> 
> Right, I found out some more about this.

TL;DR: There will need to be a refresh of this patch?
[...]
> 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)?

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.

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?

Ian.


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