On 05/20/2012 09:20 AM, Peter Krempa wrote:
On 05/19/2012 01:52 AM, Eric Blake wrote:
> Use of virConnectListDomains() and virConnectListDefinedDomains() is:
>
> +
> +int virConnectListAllDomains(virConnectPtr conn,
> + virDomainPtr *doms,
> + unsigned int flags);
My take of implementing this was basicaly identical (even the function
name). The only thing i took differently was adding a parameter
"ndomains" to enable limiting of size of the returned array. I don't
think that this will be widely used, but it might be useful to get some
of the guests if the complete list exceeds RPC limit. Do you think I
should keep it?
No. ndomains is _only_ useful if you can also control _where_ in the
list you start iterating; but that implies multiple API calls, and you
are back to the race situation. It made sense on APIs where the array
is pre-allocated by the user, but if we are doing the allocation, then
we should either successfully allocate the complete return, or return a
sensible error indicating that there are too many domains for the
current RPC limits (and which serves as a hint that using filtering bits
may be able to reduce the list into manageable chunks).
Note that some of the filtering groups are racy because they can be
modified by the guest (such as whether a guest is running or halted),
where other attributes are, to some degree, race-free if you can ensure
that no other connection can modify the same attribute at the same time
(for example, whether a guest can be autostarted can be treated as a
race-free division, if you can ensure no other connection is modifying
autostart values while you separate things into 2 probes).
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org