[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 08/12] libxl: ocaml: drop the ocaml heap lock before calling into libxl
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |