[libvirt] [RFC] virCommandRun return error number

[Eric Blake]

On 04/11/2013 08:48 AM, harryxiyou wrote:
> On Thu, Apr 11, 2013 at 10:26 PM, Eric Blake <eblake at redhat.com> wrote:
> 
> Hi Eric,
> 
> [...]
>> Not necessary.  virCommand is DESIGNED for streamlined usage, so that it
>> is much easier to read how the command is constructed without being
>> distracted by error checking in the caller every step of the way.  As a
>> virCommandPtr has no semantic impact until it is run, it is sufficient
>> to delay error checking until the caller is actually ready to run the
>> command.  Therefore, we wrote virCommandRun() to specifically check for
>> NULL, and report an error at that time, so that the caller need not
>> worry about virCommandNew* returning NULL.
>>
>> No bug here.
>>
> 
> ACK.
> However, we really need not do the following stuffs. It may affect
> efficiencies. Maybe i have thought more about this matter.

No need.  You are talking about the error path, the one that only hits
on the RARE case of OOM.  If we are OOM, we are already hosed - what
does it matter if we take a few extra calls to a few more virCommand*()
functions before finally reporting the error to the user?  All that
matters is that we are hosed gracefully (ie. that we DO report the
error, instead of crashing).

On the common case, virCommandNew*() never fails, so every step of the
way is important and there is nothing that can be shaved.  It boils down
to whether you check for NULL at every call site (a maintenance burden)
or inside every virCommand*() API - either way, a NULL check has to be
done to remain robust, but we intentionally chose the design that
results in the fewest lines of code.

There is NOTHING wrong here.  Quit trying to make a bug out of something
that's working.

One more point: libvirt is generally not the bottleneck.  Remember,
libvirt is the management, the thing that kicks off the long-running
tasks.  But the long running tasks are separate processes.  Libvirt
itself is not doing the long-running task.  Therefore, shaving a few
instructions off of libvirt is generally going to have a negligible
effect on the overall performance of your usage of the virt stack.
Focus on features, not micro-optimizations, unless you can first post
benchmarks proving that libvirt is indeed the cause of a bottleneck you
are trying to optimize.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

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