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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
