[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH C#] Always close connections and free domains

´╗┐Hmm, that's what I call a "wrapper" (I don't know if it is the good term)

I have created one for my project DAVIM.
It is almost complete, I have encapsulate IntPtr and all of this in classes.

for example I have class "LibvirtHost" and "LibvirtDomain" and "LibvirtNetwork" and so on.
Each object keep his IntPtr and expose smooth methods to use bindings.

I don't know if it can be a start point.


From: "Matthias Bolte" <matthias bolte googlemail com>
Sent: Friday, October 29, 2010 4:58 PM
To: <veillard redhat com>
Cc: <libvir-list redhat com>; <arnaud champion devatom fr>
Subject: Re: [libvirt] [PATCH C#] Always close connections and free domains

2010/10/28 Daniel Veillard <veillard redhat com>:
On Thu, Oct 28, 2010 at 12:37:18PM +0200, Matthias Bolte wrote:
Also free the unmanaged authDataPtr in the virConnectOpenAuth

 I'm no C# expert by all mean ... so I'm not sure I should comment

Same here. I'm basically applied my C++ and Java knowledge onto C# and
see how far I come with that :)

                     string domainName = Domain.GetName(domainPtr);
+                    Domain.Free(domainPtr);

 but that I wonder ... When people are used to GC'ed languages, they
hate when they have to do the cleanup themselve and end up with leaks
left and right (from experience with libxml2 python bindings...)
 Is there really no way to do some kind of automatic garbage collection
of Domain objects, or is adding this just a way to speed up the GC in
a loop ?

 otherwise patch looks 'normal' to my unexercized eye :-)


Currently the bindings are just a straightforward mapping for the C
API into C# using static methods and "void" pointers (actually
IntPtr). This basically works, but probably doesn't feel very C#'ish.

I think we might complete the bindings at this level. Once that basic
thin layer is done and all the hard problems are solved - like the
heap issue in the auth callback (has a workaround) or the integer
width on different platforms problem with the virDomainInfo struct -
then we can wrap this "first level" bindings into a more C#'ish way
with instances of the Domain class representing an underlying
virDomainPtr etc.

At that level we can use the GC and let it collect domain objects. But
we'll still keep the explicit Free() methods as in the Java bindings,
because I think that the C# GC - as most/all GC languages - doesn't
guarantee calling finalizers/destructors at all and we might end up
with leaked underlying objects. Maybe I'm wrong here, I'm not a C#
expert after all :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]