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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
