[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 29 Nov 2013, at 08:39, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > On Thu, 2013-11-28 at 18:11 +0000, Ian Jackson wrote: >> Rob Hoes writes ("RE: [PATCH v6 08/12] libxl: ocaml: drop the ocaml heap >> lock before calling into libxl"): >>> Ian Jackson wrote: >>>> I don't see here how "async" is protected from being gc'd (or, perhaps, >>>> moved by the ocaml gc) during the execution of the long-running libxl >>>> operation. The pointer to it is hidden inside the (now malloc'd) ao_how. >>>> AIUI the "CAMLparam1...CAMLreturnT" pair protect it during the aohow_val >>>> function ? >>> >>> To keep the async user values "alive", we keep them in a set in >>> OCaml for the duration of the async call. See the code that deals >>> with "async_users" in xenlight.ml.in. The GC will definitely not >>> destroy these values. >> >> Surely that can't be right. You're relying on the ocaml code to do >> the memory management right. Effectively you've made an unsafe >> interface! >> >>> I'm not sure if the GC may _move_ the value (I assumed it wouldn't)... >> >> I thought GCs in these kind of languages were entitled to move things >> to which they thought they had all the references. > > Me too, and the ocaml books explicitly say that it will, e.g. > http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora116.html > Any allocation in the Objective CAML heap can trigger a garbage > collection, which will deallocate unused memory blocks and may > move live blocks. > > Does the gc have some sort of horror mode. where it would move stuff > around at every allocation etc? Perhaps a debug option here to always > manually invoke the gc when you acquire/drop the lock and in other key > places? > > 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. Rob _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |