Re: [libvirt] (Dropping) OOM Handling in libvirt
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