[libvirt] (Dropping) OOM Handling in libvirt

[Andrea Bolognani]

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 also can't help but wonder what going in this direction would
mean for libvirt-glib and the projects built upon it...


[1] https://www.redhat.com/archives/libvir-list/2017-March/msg00008.html
-- 
Andrea Bolognani / Red Hat / Virtualization