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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

> > Also, is it really safe to bury these calls to CAMLparam1 etc. on async
> > inside aohow_val ?  AIUI these CAML gc protection things need to occur as
> > the very first thing inside the ocaml stub function, before calling
> > anything which might trigger the ocaml gc.
> 
> The CAMLparam macros indeed need to be called as soon as you enter a
> stub, but that is what we do. A function like
> stub_libxl_domain_create_new calls CAMLparam on async in the first
> line.

Right...

> I think it is good practise to just use CAMLparam + CAMLreturn in
> every function that deals with ocaml values, even if they might be
> "optimised away", just to avoid possible mistakes.

If you think so, OK.

But in this case it results in you making an overly cautious
assumption about the calling context which prevents you from calling
aohow_value inside your libxl function arguments.

Ian.

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