[Libguestfs] [PATCH 1/4] v2v: domainxml: factor out connect and pool loading

[Pino Toscano]

On Tuesday 14 April 2015 17:26:19 Richard W.M. Jones wrote:
> On Tue, Apr 14, 2015 at 05:14:50PM +0100, Richard W.M. Jones wrote:
> > As a result of this I'm always suspicious of code that calls
> > String_val, stashes the result in a variable, and then uses the result
> > over long stretches of code.  It's safer to call String_val() multiple
> > times whenever it is needed (String_val is a no-op because
> > value == char * for OCaml strings).

This is something I checked, although of course avoid being on the
"borderline" is better indeed.

> And another thing to say is if you want to pass a 'value' into other
> private functions, in order to avoid having to call String_val() until
> the last moment, then you usually need to surround those private
> functions with:
> 
>   static value internal_fn (value a)
>   {
>     CAMLparam1 (a);
>     // maybe also CAMLlocal (..);
> 
>     ...
> 
>     CAMLreturn (Val_unit);
>       // or CAMLreturnT if returning a non-value
>       // or CAMLreturn0 if returning void
>   }
> 
> These are only needed for functions that may allocate on the OCaml
> stack, eg. calling caml_alloc*, caml_copy*, etc (perhaps indirectly).
> 
> What these macros actually do is to set up a struct on the stack which
> is linked to a global list of stack frames.  If the GC moves an object
> around, then it follows this list of stack frames, finding if a value
> exists anywhere on the C stack pointing to that object, and adjusting
> the value pointer to point to wherever the object moved to.
> 
> (It's helpful to examine the macro definition in the header files to
> really see what's going on.)

This is something useful to know, thanks for the pointers.  I actually
checked the basics of these OCaml C API, although not that in-depth.

I changed patches 1 & 2 according to what you've pointed out, sending
them soon for review.

Thanks,
-- 
Pino Toscano