Re: [Xen-devel] [PATCH 0 of 3] libxl: memory leaks

[Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>]

On Tue, 2010-08-03 at 14:37 +0100, Vincent Hanquez wrote:
> On 03/08/10 13:16, Gianni Tedesco (3P) wrote:
> > I actually prefer explicit free's on the returned objects. That gives
> > callers a lot more control. Have you seen Ians patch auto-generating
> > that code? I think this approach combined with automatic-freeing of
> > scratch data used in libxl calls is the best of both worlds.
> >    
> How much control do you actually need ?
> 
> In python you'ld have the approach:
> 
> my_function_xl_binded()
> {
>   fill_structure(&structure);
>   CTX_INIT;
>   do_xl_call(&structure);
>   pyval= convert_to_python_values(&structure);
>   CTX_FREE;
>   return pyval;
> }
> 
> in OCaml exactly the same.
> 
> how is that an improvement for python and ocaml bindings that you have 
> to insert the right call in some functions to do some more freeing ?

I don't suppose it's an improvement just not a significant complication.
It does improve the situation for C callers who aren't going to want to
copy the returned values that they want to keep needlessly, it's not the
usual behaviour of libraries which return pointers to things.

Typically the compound data structures which require freeing are
encapsulated in an object in the wrapper. Just use the destructor to
free it. It also means you can use PyStaticString_* instead of
PyString_* for example.

> It also save having to generate freeing code.
> 
> > I don't know about ocaml but assume it's trivial to call a libxl_*_free
> > function when an object which encapsulates a libxl returned object is
> > destroyed?
> >    
> it's possible and not very hard, it doesn't mean that should be done though.
> I really like the braindead approch of after i called libxl_ctx_free, i 
> don't have anything to do with memory by design. You're advocating for 
> having to put the right call in the right functions in the place that 
> need it.

It prevents multiple threads using the same context safely without
serialising on those free calls. Let libxl free it's internal scratch
data, let the callers free things they've explicitly requested...

Gianni


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel