On 5/13/19 8:28 AM, Michal Privoznik wrote:
On 5/13/19 12:17 PM, 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:
The long answer follows...
I'm up for dropping OOM handling. Since we're linking with a lot of libraries I don't think we can be confident that we won't abort() even now anyway.
I can live with the decision to drop OOM handling, as long as we still try to gracefully handle any user-requested large allocation (such as g_try_malloc) and only default to abort-on-failure for the more common case of small allocations (such as g_malloc).
The implementation ==================
Assuming a decision to abort on OOM, libvirt can nwo follow QEMU's lead and make use of the GLib library.
No, please no. Firstly, glib is a new C dialect that only a few of us speak. Secondly, glib adds some padding around its objects => libvirt's memory footprint will grow. Thirdly, it's yet another library to link with (on my system libvirt links with 53 libraries already).
I'm not sold on the fact that glib will ease things, but I do agree that one reason we have avoided it so far is because of its abort-on-ENOMEM behavior, and we are now in agreement that this is no longer a blocker for using glib. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org