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

[Rob Hoes <Rob.Hoes@xxxxxxxxxx>]

> > I think the value on the heap can still move around, but registering a
> pointer to it as a root means that:
> > 1. the value does not get dropped by the GC; 2. the root/pointer will
> > be updated by the GC when the value itself moves,
> 
> There is no way this #2 can happen, the C interface takes a "value *"
> and therefore is only able to update the value and not the pointer to it.

I think the confusion here is due to the word "value".

The C type "value" is a pointer to something (an ocaml value) on the ocaml 
heap, or an integer, or a pointer to something outside the ocaml heap. See 
http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual033.html#toc143.

So when the GC updates something of the "value" type, it means that a pointer 
to something on the heap is updated.

> Do you mean:
>       foo(value for_callback)
>       {
>               value *p = malloc(SOME)
>               *p = for_callback
>               value pval = Val_ptr(p);
>               register_global(p)
>               return (something containing p)
>       }
> ?
> 
> This would make p safe to pass to libxl, where it can copy it around to
> its hearts content.

This is indeed what I mean. Here, p is a pointer to something of type "value", 
which can be updated by the GC. The thing of type "value" is itself a pointer 
to something on the ocaml heap (or an integer, or a pointer to a C variable). 
The thing on the heap can move around, which is now fine, because the pointer 
to it (the "value") can be updated by the GC.

> In this case the ocaml runtime can never change "p" from the point of view
> of the C code in order to move it around (since p is passed by value not
> reference to the registration fn). It could change *p but that doesn't
> equate to moving the value around.
> 
> Maybe we've just been talking at cross purposes?

I think we basically agree :)

Rob

> BTW I see now why
>       foo(value for_callback)
>       {
>               register_global(&for_callback)
>       }
> won't work -- &for_callback is a stack address.
> 
> Ian.

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