Re: [PATCH kvm-unit-tests 2/4] Introduce a C++ wrapper for the kvm APIs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/28/2010 04:40 PM, Michael S. Tsirkin wrote:
On Sun, Nov 28, 2010 at 03:14:17PM +0200, Avi Kivity wrote:
>  On 11/28/2010 01:44 PM, Michael S. Tsirkin wrote:
>  >On Sun, Nov 28, 2010 at 11:54:26AM +0200, Avi Kivity wrote:
>  >>   On 11/28/2010 11:50 AM, Michael S. Tsirkin wrote:
>  >>   >>    >
>  >>   >>    >Another problem is that there seem to be two memory allocations and a
>  >>   >>    >copy here, apparently just to simplify error handling.  It might be fine
>  >>   >>    >for this test but won't scale for when performance matters.
>  >>   >>
>  >>   >>    When it matters, we can fix it.  I don't see msr read/write becoming
>  >>   >>    a hot path.
>  >>   >
>  >>   >It will be very painful to fix it.
>  >>
>  >>   Why?
>  >
>  >Because the API returns a vector.
>
>  Returning an object does not involve a copy (return value optimization).

Yes, but assigning the value in the code that uses it will, unless again
you do this in an initializer.

So do that.

>
>  This code is not reusable.  Everywhere you use an fd, you have to
>  repeat this code.

But that's not a lot of code. And you can abstract it away at a higher
level. For example kvm_init and kvm_cleanup would setup/cleanup
state in a consistent way.

That's not what we see in C code. The error handling gets everywhere, obscuring what's actually going on, and usually getting it wrong by leaking.

My experience tells me C++ code has much more boilerplate code that you
are forced to repeat over and over.  This is especially true for unix
system programming:  by the time you are done wrapping all of unix you
have created more LOC than you are ever likely to save.

You don't need to wrap everything. Sometimes you can get away with if (ret == -1) throw. But things like file descriptors are essential.

>
>  class kvm::fd is reusable, if you embed it in another object you
>  don't have to worry about errors any more (as long as the object's
>  methods are exception safe).

To get exception safe code, you have to constantly worry about errors.
And it's easier to spot an unhandled return code than exception-unsafe
code:  gcc actually has  __attribute__((warn_unused_result)) which
might help catch common errors. No such tool to catch
exception-unsafe code AFAIK.

We see exactly how easy it is by the constant stream of patches that fix error paths into Linux. Most user space programs don't even care about errors because they're so difficult and annoying to get right.

>  Yes, all the correctness is more or less pointless here.  Like I
>  said, this is an experiment to see what things look like.  I guess
>  each side will it as proving its claims.

This is exactly what seems to be happening.
I did my best to try and be objective and point out real issues,
but you probably guessed which side I am on already :).

The lack of "the C++ compiler eats babies" and "line noise" comments is appreciated.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux