[libvirt] (Dropping) OOM Handling in libvirt

[Daniel P. Berrangé]

On Mon, May 13, 2019 at 02:00:28PM +0200, Andrea Bolognani wrote:
> On Mon, 2019-05-13 at 11:17 +0100, Daniel P. Berrangé wrote:
> > This is a long mail about ENOMEM (OOM) handling in libvirt. The executive
> > summary is that it is not worth the maint cost because:
> > 
> >   - this code will almost never run on Linux hosts
> >   
> >   - if it does run it will likely have bad behaviour silently dropping
> >     data or crashing the process
> > 
> >   - apps using libvirt often do so via a non-C language that aborts/exits
> >     the app on OOM regardless, or use other C libraries that abort
> > 
> >   - we can build a system that is more reliable when OOM happens by
> >     not catching OOM, instead simply letting apps exit, restart and
> >     carry on where they left off
> > 
> [...]
> > 
> > Assuming a decision to abort on OOM, libvirt can nwo follow QEMU's lead and
> > make use of the GLib library.
> 
> +1 to the idea of moving to GLib, which I guess is not at all
> surprising given that I had already suggested doing that a couple
> of years ago[1] ;)
> 
> 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 also can't help but wonder what going in this direction would
> mean for libvirt-glib and the projects built upon it...

I don't think it has a significant impact. libvirt-glib.so is just a
glue to the GLib event loop. The libvirt built-in event loop might
become the same thing.

Most of the code is in libvirt-gconfig though which is a mapping of
XML docs into the GObject model which is all still relevant.

Likewise libvirt-gobject is a remapping of libvirt public API into
GObject. If we don't expose the fact that our public API secretly
uses GObject internally, then I think libvirt-gobject is also still
valid.

Potentially we could merge libvirt-gobject into our public API
officially exposing that its GObject based, but I don't think that's
an important thing in the near future, possibly not even in the long
term. Basically I'd be cautious with our public API to avoid tieing
the public API to the internal impl choice.


Regards,
Daniel

> [1] https://www.redhat.com/archives/libvir-list/2017-March/msg00008.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 :|