[libvirt] (Dropping) OOM Handling in libvirt

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190513/ce930514/attachment-0001.sig>