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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list