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

[Rob Hoes <Rob.Hoes@xxxxxxxxxx>]

On 28 Nov 2013, at 18:11, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> 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!

Well, this ocaml code (xenlight.ml/xenlight.mli) is the thing that exposes the 
interface. And you need to use it in a certain way for it to work well. For 
example, you also need to first call the functions that register callbacks 
before you can do anything event-related.

>> 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.

We don't call aohow_value inside the libxl function arguments, because it 
accesses ocaml values while the ocaml heap lock is not held. This isn’t about 
the CAMLparam/return macros.

Rob


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