[libvirt] (Dropping) OOM Handling in libvirt

[Daniel P. Berrangé]

On Mon, May 13, 2019 at 04:33:17PM +0200, Andrea Bolognani wrote:
> On Mon, 2019-05-13 at 13:19 +0100, Daniel P. Berrangé wrote:
> > On Mon, May 13, 2019 at 02:00:28PM +0200, Andrea Bolognani wrote:
> > > One possible complication is that we would not be able to use any
> > > of the GLib types in our public API... I think the way we should
> > > approach this is to consider the current public API as if it were
> > > yet another language binding, the language being plain C in this
> > > case, and make sure we have a very well defined boundary between
> > > them and everything else, basically treating them as a separate
> > > project that just so happens to live in the same repository and be
> > > developed in tandem. This should also make it easier for us to
> > > switch to a different programming language in the future, should
> > > we decide to.
> > 
> > I'm not sure why you say we can't use GLib types in our public API ?
> > 
> > I think we could use them, but I'd probably suggest we none the less
> > choose not to use them in public API, only internally :-)
> > 
> > But I'm anticipating we could replace virObject, with GObject, and as
> > such all the virXXXXXPtr types in our public API would become GObjects.
> > I think we'd likely keep them as opaque types though, despite the fact
> > that they'd be GObjects, to retain our freedom to change impl again
> > later if we wish.
> > 
> > I won't think we need to change use of 'long long' to 'gint64', etc
> > Not least because because GLib maintainers themselves are questioning
> > whether to just mandate stdint.h types. This is fairly minor though.
> 
> I was mostly thinking about this latter example and other situations
> along those lines. For example, we'll definitely need to start using
> gchar* internally, and since we don't want that implementation detail
> exposed in our plain C bindings, then we'll have to do at least some
> very lightweight conversion (casting) between that and char*. This is
> one of the examples where considering the existing API as a language
> binding would IMHO result in a maintainable structure.
> 
> Another situation where the above model would help is error
> reporting: if we start using GLib heavily, then it might make sense
> to adopt GError as well, but doing so means we'd have to convert to
> our existing error reporting facilities somewhere. If we consider the
> plain C API to be a binding, then that's not different from what we
> already do for Python and friends.

Yep,I see what you mean.

> 
> As for GObject, yeah, we want all public structures to be opaque
> anyway; at the same time, we won't be able to turn existing
> non-opaque public structures into GObjects. I'm not sure how big of
> a deal that would be in practice, but I just thought I'd bring it up.

There is a concept called "Boxed types[1]" which lets you deal with
plain C structs using the GObject system. It is good when you have
a light weight struct where you want easy deep-copying but don't
want the overhead of a full GObject, or where you're consuming
structs defined by a 3rd party which you can't control.

But as we seem to agree, I don't think we need touch anything in
the public headers in the forseable future, so don't have to worry
about that.

Regards,
Daniel

[1] https://developer.gnome.org/gobject/stable/gobject-Boxed-Types.html
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|