On Mon, May 13, 2019 at 03:28:24PM +0200, Michal Privoznik wrote:
On 5/13/19 12:17 PM, Daniel P. Berrangé wrote:The tests show we generally do remarkly well at OOM handling, but none the less we have *always* found bugs in our handling where we fail to report the OOM (as in, continue to run but with missing data), or we crash when cleaning up from OOM. Our unit tests don't cover anywhere near all of our codebase though. We have great coverage of XML parsing/formatting, and sporadic coverage of everything else. IOW, despite our clever API designs & coding patterns designed to improve our OOM handling, we can not have confidence that we will actually operate correctly in an OOM scenario.I beg to disagree. The fact that our cleanup paths are in 99% the same as error paths means that if there are no mem-leaks (and if transformation to VIR_AUTOFREE is done the chances are low), then we propably do good on OOM too.
There possibly might be cases where we dereference the pointer unconditionally in the cleanup section, regardless of whether the allocation succeeded.
<snip/>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.
Well, libvirt C is also a dialect that is even less widely spoken. Moreover, it will make it easier for QEMU developers to contribute to libvirt and vica verca. Also, learning it is much easier than learning a different language (Rust? Haskell?)
Secondly, glib adds some padding around its objects => libvirt's memory footprint will grow.
We also do a lot of unnecessary (re)allocations to simplify the code, the logic being that the extra developer time spent debugging is not worth the neligible increase. But this seems like something that's hard to measure until we rewrite all of libvirt in glib.
Thirdly, it's yet another library to link with (on my system libvirt links with 53 libraries already).
Well, if you already have to have glib because of QEMU, why does the library count matter? Jano
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
